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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jens Bauer <jens-lists@gpio.dk> writes:
> Hi Andreas and Richard.
>
> On Thu, 09 May 2013 22:37:14 +0200, Andreas Schwab wrote:
>> Jens Bauer <jens-lists@gpio.dk> writes:
>> 
>>> Hmm.. I get an error, when I try to build the code with...
>>> 	.section .fastcode, "ax", @progbits
>>> ...It doesn't like the extra parameters:
>> 
>> arm uses @ as the comment character, replace it by %.

Sorry, I should have remembered that.

> Thank you very much, Andreas, this has been very valuable for me in
> narrowing down the problem.
> I just tried using...
> 	.section	.fastcode,"ax",%progbits
> ...And I got it to build, plus the entire code-block including LDR and
> STR is now placed correctly in SRAM.

Good!  This is the right fix btw, rather than a workound.  Still...

> Richard, I think you now have a much better idea of what is going on, am
> I right ?

...yeah.  The problem is that plain ".section .foo" creates a section
without the SHF_ALLOC flag.  In the working .elf file, the section gets
marked allocatable by the linker:

  [ 2] .fastcode         PROGBITS        10000000 010000 00000c 00   A  0   0  2

which in turn causes .fastcode to be included in the .hex file.  In the
broken .elf file, the flag stays clear:

  [ 2] .fastcode         PROGBITS        10000000 008400 00000c 00      0   0  2

and so .fastcode isn't included in the .hex file.

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.

2-byte instructions like "str r1, [r0, #0]" cause the input .fastcode
section to be exactly 12 bytes long, so no padding is needed and the
section isn't included.  Removing the instruction, or inserting a 4-byte
instruction like "str r1, [r0, #200]", causes .fastcode to be 10 or 14
bytes long respectively, so alignment is needed and the section is included.

This behaviour actually seems to be deliberate:

	case lang_data_statement_enum:
	  /* Make sure that any sections mentioned in the expression
	     are initialized.  */
	  exp_init_os (s->data_statement.exp);
	  /* The output section gets CONTENTS, ALLOC and LOAD, but
	     these may be overridden by the script.  */
	  flags = SEC_HAS_CONTENTS | SEC_ALLOC | SEC_LOAD;

(i.e. you have to use something like INFO in order to preserve the
unallocatable state).  It seems really nonobvious though...

Richard