This is the mail archive of the
mailing list for the binutils project.
Re: Possible bug; code-block vanishes when adding one assembler-instruction.
- From: Jens Bauer <jens-lists at gpio dot dk>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, binutils at sourceware dot org
- Date: Wed, 15 May 2013 06:17:11 +0200
- Subject: Re: Possible bug; code-block vanishes when adding one assembler-instruction.
- References: <20130507122903314912 dot 0457de47 at gpio dot dk> <87sj1xv0bs dot fsf at talisman dot default> <20130508213144132481 dot 9400973e at gpio dot dk> <877gj83448 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <20130509113822748942 dot 6df40120 at gpio dot dk> <87sj1w1nt4 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <20130509203639970923 dot 8532796d at gpio dot dk> <874nebhoud dot fsf at hase dot home> <20130509230759849349 dot 2f104060 at gpio dot dk> <87fvxvtblq dot fsf at talisman dot default> <20130510133705897264 dot dfd51dcb at gpio dot dk> <87obcdsagq dot fsf at talisman dot default>
>> 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.