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: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jens Bauer <jens-lists at gpio dot dk>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, binutils at sourceware dot org
- Date: Tue, 14 May 2013 19:05:57 +0100
- 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>
Jens Bauer <firstname.lastname@example.org> writes:
>> The difference comes from whether the alignment in:
>> . = ALIGN (4);
>> _efastcode = . ;
>> actually does anything or not. If the address is already correctly
>> aligned, because the size of the input .fastcode section is divisible by 4,
>> the section stays unallocatable. If the assignment to "." increases the
>> address (inserts padding) then the section becomes allocatable.
> 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.
> -But... I think the assembler could be improved slightly here.
> It isn't often that the .section directive is used in an assembly-source file.
> -So if it's used, the user _really_wants_ the output, I believe.
> Especially if the user created a .section .freddy, which was followed by
> assembly-language instructions (or any indication of using instructions
> inside the section), in my opinion, it would be right to mark it as "ax"
> ...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:
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.)
> ...Or perhaps even more foolproof... Mark section with all flags (I
> know, this may be silly) ?
> What I'm trying to say is that.. Either put up an error and complain or
> stay on the safe side. ;)
Complaining is probably better than trying to second-guess.
I agree that warning when inserting code into an implicitly
non-executable section might make sense. Unfortunately,
because of the way gas is structured, it might be quite
tricky to implement...