Load addresses for ELF program headers on ARM

Load addresses for ELF program headers on ARM

[Matt Fischer]

I'm trying to link an executable for bare-metal ARM, and am running
across something that seems like it's in violation of ARM's ELF spec.
I'm still learning some of this, so please let me know if this is just
a misunderstanding on my part.

I'm attempting to make a ROM-style executable, where the data segment
is tacked onto the end of the text segment, and code in the startup
routine copies it to its final address in RAM.  Here's a test program,
and the corresponding linker script:

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

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

I'm attempting to give the TEXT section an address of 0, and then give
the DATA segment a relocation address of 0x10000000, but a load
address directly after the text segment.  After linking this program,
the resulting executable has the following:

Section Headers:
 [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
 [ 1] TEXT              PROGBITS        00000000 008000 0000b4 00 WAX  0   0  4
 [ 2] DATA              PROGBITS        10000000 010000 000008 00  WA  0   0  4

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

The linker created two program headers, one for TEXT, and one for
DATA.  The TEXT one looks fine--both vaddr and paddr are at 0.  The
DATA segment, however, has a problem.  It's been given a vaddr of
0x10000000, and a paddr of 0x000000b4.  The former is the section's
relocation address, and the latter is its load address.  However, the
ARM spec for ELF states that segments should have vaddr set to their
load address, and paddr set to 0 .  Is there a way to convince the
linker to do this?

Thanks,
Matt

P.S.  After typing all of this, I ran across
http://cygwin.ru/ml/binutils/2002-09/msg00516.html, which basically
seems to describe my problem.  Is this pretty much just broken by
design, then, or is there some way around it?  The reason it's a
problem for me is that I may be using these executables with other
tools which do obey the ARM spec, so as it stands they will try to put
code in the wrong places.

Re: Load addresses for ELF program headers on ARM

[Alan Modra]

On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote:
> The linker created two program headers, one for TEXT, and one for
> DATA.  The TEXT one looks fine--both vaddr and paddr are at 0.  The
> DATA segment, however, has a problem.  It's been given a vaddr of
> 0x10000000, and a paddr of 0x000000b4.  The former is the section's
> relocation address, and the latter is its load address.  However, the
> ARM spec for ELF states that segments should have vaddr set to their
> load address, and paddr set to 0.

Which ARM ELF spec are you talking about?  An old and buggy one, I'd
guess.  If the one you're looking at says that it is clearly in
conflict with the parent SysV ELF ABI spec.  This spec
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf
is silent on p_vaddr and p_paddr.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

Ok, that makes sense.  So if I really do want to create one blob which
will then perform its own relocations, it looks like I need to just
put both of those sections into a single program header.  It seems
like I ought to be able to do that with the following script:

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

PHDRS
{
  main PT_LOAD;
}

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?

Thanks,
Matt

On Sun, Oct 10, 2010 at 8:55 PM, Alan Modra <amodra@gmail.com> wrote:
> On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote:
>> The linker created two program headers, one for TEXT, and one for
>> DATA.  The TEXT one looks fine--both vaddr and paddr are at 0.  The
>> DATA segment, however, has a problem.  It's been given a vaddr of
>> 0x10000000, and a paddr of 0x000000b4.  The former is the section's
>> relocation address, and the latter is its load address.  However, the
>> ARM spec for ELF states that segments should have vaddr set to their
>> load address, and paddr set to 0.
>
> Which ARM ELF spec are you talking about?  An old and buggy one, I'd
> guess.  If the one you're looking at says that it is clearly in
> conflict with the parent SysV ELF ABI spec.  This spec
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf
> is silent on p_vaddr and p_paddr.
>
> --
> Alan Modra
> Australia Development Lab, IBM
>

Re: Load addresses for ELF program headers on ARM

[Daniel Jacobowitz]

On Mon, Oct 11, 2010 at 12:25:06PM +1030, Alan Modra wrote:
> On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote:
> > The linker created two program headers, one for TEXT, and one for
> > DATA.  The TEXT one looks fine--both vaddr and paddr are at 0.  The
> > DATA segment, however, has a problem.  It's been given a vaddr of
> > 0x10000000, and a paddr of 0x000000b4.  The former is the section's
> > relocation address, and the latter is its load address.  However, the
> > ARM spec for ELF states that segments should have vaddr set to their
> > load address, and paddr set to 0.
> 
> Which ARM ELF spec are you talking about?  An old and buggy one, I'd
> guess.  If the one you're looking at says that it is clearly in
> conflict with the parent SysV ELF ABI spec.  This spec
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf
> is silent on p_vaddr and p_paddr.

My memory on this is a bit vague, but I think that the ARM debugger
does behave as Matt described (or used to).  You should be able to
post-process the file, either with objcopy or a custom utility; it
will be a simple one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

On Sun, Oct 10, 2010 at 9:50 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Mon, Oct 11, 2010 at 12:25:06PM +1030, Alan Modra wrote:
>> On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote:
>> > The linker created two program headers, one for TEXT, and one for
>> > DATA.  The TEXT one looks fine--both vaddr and paddr are at 0.  The
>> > DATA segment, however, has a problem.  It's been given a vaddr of
>> > 0x10000000, and a paddr of 0x000000b4.  The former is the section's
>> > relocation address, and the latter is its load address.  However, the
>> > ARM spec for ELF states that segments should have vaddr set to their
>> > load address, and paddr set to 0.
>>
>> Which ARM ELF spec are you talking about?  An old and buggy one, I'd
>> guess.  If the one you're looking at says that it is clearly in
>> conflict with the parent SysV ELF ABI spec.  This spec
>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf
>> is silent on p_vaddr and p_paddr.
>
> My memory on this is a bit vague, but I think that the ARM debugger
> does behave as Matt described (or used to).  You should be able to
> post-process the file, either with objcopy or a custom utility; it
> will be a simple one.

This is second-hand information, but what I've been told is that the
ARM debugger does indeed behave that way--that's the main use-case I'm
trying to cover here.  If that's the case, it sounds like the best way
forward is just to create an image with multiple program headers, and
then post-process them to have the load address in the vaddr field,
even though that's not to spec.  I'm new to objcopy--does it have
facilities for changing the program headers?  Most of its options just
seem to be geared around messing with the section headers.

--Matt

Re: Load addresses for ELF program headers on ARM

[Alan Modra]

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.)

-- 
Alan Modra
Australia Development Lab, IBM

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

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?

--Matt

Re: Load addresses for ELF program headers on ARM

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

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. :)

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

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. :)

Re: Load addresses for ELF program headers on ARM

[Alan Modra]

You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in
elf.c:_bfd_elf_make_section_from_shdr to
ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

That does seem to fix the problem.  It looks like that change simply
disables the VMA check on the section, which makes sense because in
this model the section's VMA won't be inside of the segment anymore.
Given that the code inside this block looks like it can correctly deal
with a segment that contains noncontiguous VMA's, I'm assuming this
change is ok to submit as an actual patch, correct?  If so, I'd be
happy to write it up and submit it, if you'd like.

--Matt

On Tue, Mar 15, 2011 at 11:29 PM, Alan Modra <amodra@gmail.com> wrote:
> You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in
> elf.c:_bfd_elf_make_section_from_shdr to
> ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens.
>
> --
> Alan Modra
> Australia Development Lab, IBM
>

Re: Load addresses for ELF program headers on ARM

[Alan Modra]

On Wed, Mar 16, 2011 at 07:37:30PM -0500, Matt Fischer wrote:
> That does seem to fix the problem.  It looks like that change simply
> disables the VMA check on the section, which makes sense because in
> this model the section's VMA won't be inside of the segment anymore.
> Given that the code inside this block looks like it can correctly deal
> with a segment that contains noncontiguous VMA's, I'm assuming this
> change is ok to submit as an actual patch, correct?  If so, I'd be
> happy to write it up and submit it, if you'd like.

I figured the change would fix your particular testcase.  The
difficult part of "see what happens" is determining what this change
might break, and convincing me or another binutils maintainer that the
change is safe..  At the moment I don't have time to investigate that
myself.

> 
> --Matt
> 
> On Tue, Mar 15, 2011 at 11:29 PM, Alan Modra <amodra@gmail.com> wrote:
> > You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in
> > elf.c:_bfd_elf_make_section_from_shdr to
> > ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Load addresses for ELF program headers on ARM

[Matt Fischer]

On Wed, Mar 16, 2011 at 9:38 PM, Alan Modra <amodra@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 07:37:30PM -0500, Matt Fischer wrote:
>> That does seem to fix the problem.  It looks like that change simply
>> disables the VMA check on the section, which makes sense because in
>> this model the section's VMA won't be inside of the segment anymore.
>> Given that the code inside this block looks like it can correctly deal
>> with a segment that contains noncontiguous VMA's, I'm assuming this
>> change is ok to submit as an actual patch, correct?  If so, I'd be
>> happy to write it up and submit it, if you'd like.
>
> I figured the change would fix your particular testcase.  The
> difficult part of "see what happens" is determining what this change
> might break, and convincing me or another binutils maintainer that the
> change is safe..  At the moment I don't have time to investigate that
> myself.
>

That's fair.  I admit this is a pretty odd edge case, and while it
happens to come up in the specific thing I'm working on, that doesn't
necessarily make it an overall priority for you guys.  I'll try to
take a bit of time to familiarize myself with the code, and see if I
can make a case for it going in.  And if nothing else, I can at least
keep it as a local patch for the thing I'm working on.  Thanks for all
your help.

--Matt