Using FILL(n) or =FILLEXP in linker scripts

Using FILL(n) or =FILLEXP in linker scripts

[Ti Strga]

Hello.

The super short version of our question is:  are FILL/FILLEXPs actually
written out to the ELF file, like initialized data?  Or are they just
stored as a "do this at startup", like .bss sections?

We are using a custom linker script with GNU ld 2.17 targeting powerpc-elf
(embedded, no OS yet, bare metal, etc).  It started as a copy of the stock
elf32ppc.x script, heavily modified by somebody who does not really know
compilers and is learning about linker scripts as he goes (me).

Under normal conditions, we have some output sections listed, and after
the sections we define some symbols to delimit two subsequent "chunks"
of memory.  Example with internal confusing names replaced:

.....
.last_example_block : {
    .......
    __last_example_block_end = .;
} > ram

/* Chunk one runs from the end of the last block to here. */
. = . + _CHUNK_ONE_SIZE;
. = ALIGN(16);
__chunk_one_top = .;

/* Chunk two follows, with its own markers. */
__chunk_two_bottom = .;
. = . + _CHUNK_TWO_SIZE;
. = ALIGN(16);
__chunk_two_top = .;

That all works fine.  (Based on ld.info, I think the ALIGN statement is
supposed to be able to be merged with the "sizing" statement preceding
it, but we couldn't get that syntax to work.  No big deal.)

Here's the problem:  for debugging, we'd like to occasionally fill either
of those "chunks" with a constant pattern; typically, the second of the
two chunks.  Fill expressions only work within section blocks according
to the manual, so we replace the last bit of that script with:

.internal_chunk_two : {
    FILL(0xDEADBEEF)           /* attempt one */
    __chunk_two_bottom = .;
    . = . + _CHUNK_TWO_SIZE;
    . = ALIGN(16);
    __chunk_two_top = .;
} > ram =0xDEADBEEF           /* attempt two */

Neither FILL nor FILLEXP work here.  We get two things wrong:  first,
the ELF file as written to disk doesn't contain our fill pattern.
The file *is* much larger, as one would expect -- it's writing out the
contents of that chunk instead of just storing the endpoints.  But the
contents are all explicit zeros.

The second problem is that the two chunks overlap.  Using the example
names, the new .internal_chunk_two is being placed immediately
after .last_example_block, and so __last_example_block_end and
__chunk_two_bottom have the same address.  (The first "chunk" is
typically small, so it ends up actually *inside* the second one, with
ensuing hilarity.)

Our questions:
(1)  What are we doing wrong with the fill expression?
(2)  Shouldn't the line ". = . + _CHUNK_ONE_SIZE;" have moved the location
counter forward in memory for the references in .internal_chunk_two?
We seem to have worked around the issue by using "__chunk_two_bottom =
__chunk_one_top;" in that output section, but I don't know if that's
the correct solution, or why the first way isn't working.


Any light which anyone could shed would be very appreciated.

Ti

Re: Using FILL(n) or =FILLEXP in linker scripts

[Alan Modra]

On Thu, Aug 09, 2007 at 02:19:01PM -0400, Ti Strga wrote:
> .internal_chunk_two : {
>     FILL(0xDEADBEEF)           /* attempt one */
>     __chunk_two_bottom = .;
>     . = . + _CHUNK_TWO_SIZE;
>     . = ALIGN(16);
>     __chunk_two_top = .;
> } > ram =0xDEADBEEF           /* attempt two */
> 
> Neither FILL nor FILLEXP work here.

> Our questions:
> (1)  What are we doing wrong with the fill expression?

The reason the fill isn't working is that ld treats this section like
a bss section.  It doesn't have any input sections containing data,
nor does it have any data statements.  You could argure that a
non-zero fill ought to force a normal section, ie. you've struck a ld
bug.

> (2)  Shouldn't the line ". = . + _CHUNK_ONE_SIZE;" have moved the location
> counter forward in memory for the references in .internal_chunk_two?

No.  You are using memory regions, with .internal_chunk_two belonging
to "ram".  The ". = . + _CHUNK_ONE_SIZE;" is not inside an output
section statement, so this increases "dot" in the default memory
region.  The value of "dot" in "ram" isn't changed.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Using FILL(n) or =FILLEXP in linker scripts

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Friday 10 August 2007, Alan Modra wrote:
> On Thu, Aug 09, 2007 at 02:19:01PM -0400, Ti Strga wrote:
> > .internal_chunk_two : {
> >     FILL(0xDEADBEEF)           /* attempt one */
> >     __chunk_two_bottom = .;
> >     . = . + _CHUNK_TWO_SIZE;
> >     . = ALIGN(16);
> >     __chunk_two_top = .;
> > } > ram =0xDEADBEEF           /* attempt two */
> >
> > Neither FILL nor FILLEXP work here.
> >
> > Our questions:
> > (1)  What are we doing wrong with the fill expression?
>
> The reason the fill isn't working is that ld treats this section like
> a bss section.  It doesn't have any input sections containing data,
> nor does it have any data statements.  You could argure that a
> non-zero fill ought to force a normal section, ie. you've struck a ld
> bug.

could you also argue that an explicit 0 fill should force a normal section ?  
in other words, you want a .bss like section to be zero filled both on disk 
as well as in memory at runtime ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]