This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible bug; code-block vanishes when adding one assembler-instruction.

Hi Richard.

>> OK. I would say that the correct behaviour in this case, would be to not
>> include anything at all; how silly it may sound. ;)
> I agree.  The linker ought to do the same thing regardless of whether
> an assignment inserts zero or nonzero padding.  I'm afraid of doing
> anything for compatibility reasons though.

I absolutely understand. But consistency is also very important. ;)
...But then again...
Would it matter ?
Eg. a user wrote some code, which contains a '.section .foo', and it "seems to work".
The user already wrote some unreliable code.
This code block might disappear without warning next time the user compiles the sources anyway (just a small change can cause this, like changing a value from 512 to 511).
If the behaviour is undocumented / unpredictable, I do not think it's wrong to change it into being predictable / documented.

(Anyone - feel free to comment on this)

It would be possible in the linker to detect if the 'new' behaviour is in action; eg. whether or not the section would have been included as it was before and whether or not the section will be included now.
So the user could get a warning that the section will be removed, if necessary.

>> ...Or the assembler could perhaps mark bare .section .foo as
>> "ax"/progbits by default; I guess it would be possible to create a plain
>> .section .foo, by just using
>> 	.section	.foo,"",@nobits
> Backwards compatibility would be a problem here too though.
> Particularly since marking something as executable when we aren't sure
> isn't always the safe option, especially from a security point of view.
> E.g. things like .gnu.warning sections are like your .foo above,
> but tend not to have the '"", @nobits'.  Lines like:
>       .section .rodata
> are also common -- at least from a quick scan of glibc -- and .rodata
> shouldn't be executable.  (.rodata itself is treated specially by gas
> and gets the allocatable flag, but maybe people are following this
> example for other sections that gas doesn't know about, just like
> .fastcode vs .text in your case.)

Actually, it was because I saw the way '.section .rodata' was used, I used '.section .fastcode' the same way.
Yep, that was still my fault, that I did not read about how to use .section, before using it.

You're right that it's probably too late to change the behaviour of .section.
A section should be just 'a section that can hold anything' by default, but the default behaviour can not be changed now.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]