Re: Load addresses for ELF program headers on ARM

[Matt Fischer <mattfischer84 at gmail dot com>]

Sorry to resurrect this old thread, but I'm finally following up on
this, and had a couple more questions.

I've pulled in the newest version of binutils, which has the fix that
Alan mentions above.  The test program I used above now generates the
expected results:

int x=5;
void _start()
{
 int y = x;
}

SECTIONS
{
  TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array)
*(.jcr)} :main
  DATA 0x10000000 : AT( LOADADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) } :main
}

PHDRS
{
  main PT_LOAD;
}

I now see the following in readelf:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] TEXT              PROGBITS        00000000 008000 0000b4 00 WAX  0   0  4
  [ 2] DATA              PROGBITS        10000000 0080b4 000008 00  WA  0   0  4
  [ 3] .bss              NOBITS          10000008 0080bc 000001 00  WA  0   0  1
  [ 4] .ARM.attributes   ARM_ATTRIBUTES  00000000 0080bc 000030 00      0   0  1
  [ 5] .comment          PROGBITS        00000000 0080ec 00002a 01  MS  0   0  1
  [ 6] .shstrtab         STRTAB          00000000 008116 000043 00      0   0  1
  [ 7] .symtab           SYMTAB          00000000 0082c4 000260 10      8  32  4
  [ 8] .strtab           STRTAB          00000000 008524 0000df 00      0   0  1

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x008000 0x00000000 0x00000000 0x000bc 0x000bd RWE 0x8000

 Section to Segment mapping:
  Segment Sections...
   00     TEXT

The two sections I've set up are packed contiguously into a single
program header, even though their relocation addresses are far apart
in memory, because I've instructed them to have their load addresses
adjacent to each other using the AT() keyword.  So far so good.

However, if I now attempt to objcopy this with '-O binary', it seems
to ignore the load addresses of the sections, and tries to construct a
huge file with the two sections at their relocation addresses.  It
seems like this is a bug, because it's ignoring the load addresses of
the sections.  Is this correct, or am I misunderstanding what objcopy
is supposed to do in this case?

Interestingly, objcopy does still do the right thing if I allow the
sections to be placed in separate program headers.  That is, if I do
the following:

SECTIONS
{
  TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array) *(.jcr)}
  DATA 0x10000000 : AT( LOADADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) }
}

giving me this:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] TEXT              PROGBITS        00000000 008000 0000b4 00 WAX  0   0  4
  [ 2] DATA              PROGBITS        10000000 010000 000008 00  WA  0   0  4
  [ 3] .bss              NOBITS          10000008 010008 000001 00  WA  0   0  1
  [ 4] .ARM.attributes   ARM_ATTRIBUTES  00000000 010008 000030 00      0   0  1
  [ 5] .comment          PROGBITS        00000000 010038 00002a 01  MS  0   0  1
  [ 6] .shstrtab         STRTAB          00000000 010062 000043 00      0   0  1
  [ 7] .symtab           SYMTAB          00000000 010210 000260 10      8  32  4
  [ 8] .strtab           STRTAB          00000000 010470 0000df 00      0   0  1

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x008000 0x00000000 0x00000000 0x000b4 0x000b4 RWE 0x8000
  LOAD           0x010000 0x10000000 0x000000b4 0x00008 0x00009 RW  0x8000

 Section to Segment mapping:
  Segment Sections...
   00     TEXT
   01     DATA .bss

then objcopy correctly places both sections next to each other in the
binary file, at their load addresses.  I can't tell what it's getting
hung up on in the first case that causes it to think the sections need
to be placed at their relocation addresses.

Another thing I noticed, which is possibly related, is that when
readelf looks at the program headers in the first example, it can't
figure out the section to segment mapping correctly.  Even though
TEXT, DATA, and .bss are all located in the single phdr, it only shows
TEXT.  Is this confusion about where things live related to objcopy's
inability to correctly convert the binary?

In either case, does this look like a bug in the tool, or a bug in my
understanding of how to use it?  :)

Thanks,
Matt

On Mon, Oct 11, 2010 at 10:21 AM, Matt Fischer <mattfischer84@gmail.com> wrote:
>
> On Mon, Oct 11, 2010 at 9:44 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> > On Sun, Oct 10, 2010 at 10:38:59PM -0500, Matt Fischer wrote:
> >> On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra <amodra@gmail.com> wrote:
> >> > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote:
> >> >> However, when I do this, it creates one gigantic segment which has
> >> >> both sections at their relocation addresses, and zero-fills the 200MB
> >> >> or so in between them. ?It seems like the linker is not correctly
> >> >> respecting load addresses when it tries to fit sections into segments.
> >> >> ?Is that something that can be gotten around somehow?
> >> >
> >> > This is a 2.20 bug. ?With current mainline you'll get a warning
> >> > ?section `DATA' can't be allocated in segment 0
> >> > but ld will place DATA immediately after TEXT in the segment. ?The
> >> > warning is because the VMA for DATA is outside the virtual addresses
> >> > covered by your program header. ?(The warning should probably say
> >> > something to that effect rather than "can't be allocated" when the
> >> > section *is* allocated there.)
> >>
> >> Ah, excellent. ?Ok, so I'll just patch the binaries for now, and then
> >> pick up that change once it's available. ?Dan, any idea when that fix
> >> will make its way into Sourcery Lite?
> >
> > A bit off topic for this list but... If this fix is in
> > assign_file_positions_for_load_sections, which I think it is,
> > then it will be in our November releases.
>
> Perfect. ?Thanks to both of you for all your help with this.
>
> --Matt
>
> P.S. ?Dan--sorry, you're right, I should have queried for the Sourcery
> info elsewhere. ?Thanks for obliging me, though. :)