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: Fri, 10 May 2013 13:37:05 +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>
On Fri, 10 May 2013 10:42:25 +0100, Richard Sandiford wrote:
>> I just tried using...
>> .section .fastcode,"ax",%progbits
>> ...STR is now placed correctly in SRAM.
> Good! This is the right fix btw, rather than a workound. Still...
:) My first workaround was to put all the code in the .text section and then copy it to RAM, but then I was so lucky that Andreas interrupted me, and I didn't have to finish my workaround. It *is* much better to do it the right way.
> 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. ;)
-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
...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. ;)
I'm suggesting this, because I came from a number of different assemblers myself, where it's not possible to supply flags or other arguments to .section.
I saw code for the GNU assembler with only the bare ".section .foo", so it didn't strike me that this could actually fix the problems.
It would be easy for other people to make the same mistake that I made; of course, I'm quite safe now, so I don't expect that I'll be stuck that way again. ;)