ARM ELF p_paddr is not put to zero

ARM ELF p_paddr is not put to zero

[Drasko DRASKOVIC]

Hi all,
ARM ELF specification demands that p_paddr is set to 0.

I saw however some ARM ELF binaries not having p_paddr set to zero,
but having the same p_paddr as p_vaddr. Why is that ?

Best regards,
Drasko

Re: ARM ELF p_paddr is not put to zero

[Ian Lance Taylor]

Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:

> ARM ELF specification demands that p_paddr is set to 0.

There are several ARM ELF specifications, so you need to be more
precise.  I don't see this requirement in the EABI 2.08 docs.

> I saw however some ARM ELF binaries not having p_paddr set to zero,
> but having the same p_paddr as p_vaddr. Why is that ?

That is the default behaviour for the GNU tools, so that it is possible
to represent a load address separate from the virtual address.  So most
likely this unusual ARM ELF requirement has simply not been implemented.

Ian

Re: ARM ELF p_paddr is not put to zero

[Drasko DRASKOVIC]

On Wed, Jun 22, 2011 at 5:27 PM, Ian Lance Taylor <iant@google.com> wrote:
> Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:
>
>> ARM ELF specification demands that p_paddr is set to 0.
>
> There are several ARM ELF specifications, so you need to be more
> precise.  I don't see this requirement in the EABI 2.08 docs.

Hi Ian,
I was referring to the document ARM DUI 00101-A. Now I see that it is
rather old.

But again, in the document SWS ESPC 0003 B-02, a document from 2001.
there is written:

4.6 Program headers
Figure 4-16, Program header fields for ARM executables
...
p_vaddr The virtual address at which the segment should be loaded.
This must be 0 modulo 4.
p_paddr Unused in the ARM EABI. Set to zero by ARM tools.
...

However, in  the ABI 2.08 doc ARM IHI 0049A, in the THE ABI EXTENSION
(which is optional and not obligatory for ABI compliant toolchains) :

3.2
Linker obligations
A linker claiming to support the debugging of overlaid programs shall
ensure the following in the executable ELF files it produces.
...
 - Target addresses recorded in section header sh_addr fields and
symbol st_value fields shall be execution addresses.
 - Target addresses recorded in p_paddr fields of program headers of
type PT_LOAD shall be load addresses.
...


>> I saw however some ARM ELF binaries not having p_paddr set to zero,
>> but having the same p_paddr as p_vaddr. Why is that ?
>
> That is the default behaviour for the GNU tools, so that it is possible
> to represent a load address separate from the virtual address.
What do you exactly mean by this default behaviour ? To put p_paddr =
p_vaddr ? In which situations ?

>  So most
> likely this unusual ARM ELF requirement has simply not been implemented.

Would that say that GNU ld is ARM EABI (ABI v. 2.0, published after
December 2003), but *not* OABI (ABI v. 1.0, prior to December 2003)
compliant, because of p_paddr != 0 ?

BR,
Drasko

Re: ARM ELF p_paddr is not put to zero

[Ian Lance Taylor]

Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:

>> That is the default behaviour for the GNU tools, so that it is possible
>> to represent a load address separate from the virtual address.
> What do you exactly mean by this default behaviour ? To put p_paddr =
> p_vaddr ? In which situations ?

Conceptually, every section has a virtual address (the address where the
section should live when the program is run) and a load address (the
address where the section should be loaded).  On a virtual memory
machine these are normally the same.  On a device without virtual memory
and with ROM, it is often useful to load the initialized data section at
one address (in ROM) but to run with the data at another address (in
RAM).  Given that, it becomes useful to use some mechanism for
representing both the load address and the virtual address in a linked
executable.  The GNU tools normally store the load address in the
p_paddr field and the virtual address in the p_vaddr field.

>>  So most
>> likely this unusual ARM ELF requirement has simply not been implemented.
>
> Would that say that GNU ld is ARM EABI (ABI v. 2.0, published after
> December 2003), but *not* OABI (ABI v. 1.0, prior to December 2003)
> compliant, because of p_paddr != 0 ?

It is certainly true that GNU ld strives to be EABI compliant.

Ian

Re: ARM ELF p_paddr is not put to zero

[Drasko DRASKOVIC]

On Wed, Jun 22, 2011 at 9:43 PM, Ian Lance Taylor <iant@google.com> wrote:
> Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:
>
>>> That is the default behaviour for the GNU tools, so that it is possible
>>> to represent a load address separate from the virtual address.
>> What do you exactly mean by this default behaviour ? To put p_paddr =
>> p_vaddr ? In which situations ?
>
> Conceptually, every section has a virtual address (the address where the
> section should live when the program is run) and a load address (the
> address where the section should be loaded).  On a virtual memory
> machine these are normally the same.  On a device without virtual memory
> and with ROM, it is often useful to load the initialized data section at
> one address (in ROM) but to run with the data at another address (in
> RAM).  Given that, it becomes useful to use some mechanism for
> representing both the load address and the virtual address in a linked
> executable.  The GNU tools normally store the load address in the
> p_paddr field and the virtual address in the p_vaddr field.

Hi Ian,
thanks for clarifications. I think that p_vaddr can be affected with
by --entry flag and  explicit address, as it sound logical to me that
it is set to this value. Is this correct ? Does this flag however also
affects p_paddr at the same time ?

How do we specify p_paddr (I am talking about ROM and noMMU devices)?
I.e. how do we tell at which address binary should be loaded ? Is this
done only via linker script or there are some command line options
with which we can define lma ?

Third question is - what happens if we do not define load address at
all, just provide address at we want to link, i.e. address of the
first symbol (if this does not affect p_paddr just p_vaddr) ? How does
ld manage this internally - would it equalize p_paddr to p_vaddr
during the process and spit out binary with p_paddr = p_vaddr ?

>>>  So most
>>> likely this unusual ARM ELF requirement has simply not been implemented.
>>
>> Would that say that GNU ld is ARM EABI (ABI v. 2.0, published after
>> December 2003), but *not* OABI (ABI v. 1.0, prior to December 2003)
>> compliant, because of p_paddr != 0 ?
>
> It is certainly true that GNU ld strives to be EABI compliant.

Yes, and this makes a lot of sense - rather than strive for 10 years
old proprietary vendor standard.

Let me explain in a little more details why I am asking the questions
from above.

I got interested into this subject by working on OpenOCD
(http://openocd.berlios.de/web/), which currently discovers ELF image
load address by reading elf->segments[i].p_paddr. As this is low-level
JTAG debugger, it looks quite fine and consistent with you said before
p_paddr is lma for noMMU, ROM and similar embedded stuff.

However, I run recently into an ARM ELF that looked like this :

Program Headers:
 Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 LOAD           0x000074 0x00008000 0x00000000 0xe1f18 0xe1f18 RWE 0x1
 LOAD           0x0e1f8c 0x0060f028 0x00000000 0x1103f 0x1103f RWE 0x1

and normally, OpenOCD was trying to put it to address 0x0, which is
wrong. And it's wrong because ARM OEBI obviously demands p_paddr to be
zero.

However, GDB could cope with it and load ELF normally. So I started
digging in BFD code and discovered something like this in elf.c :
if ((flags & SEC_ALLOC) != 0)
   {
     Elf_Internal_Phdr *phdr;
     unsigned int i, nload;

     /* Some ELF linkers produce binaries with all the program header
        p_paddr fields zero.  If we have such a binary with more than
        one PT_LOAD header, then leave the section lma equal to vma
        so that we don't create sections with overlapping lma.  */
     phdr = elf_tdata (abfd)->phdr;
     for (nload = 0, i = 0; i < elf_elfheader (abfd)->e_phnum; i++, phdr++)
       if (phdr->p_paddr != 0)
         break;
       else if (phdr->p_type == PT_LOAD && phdr->p_memsz != 0)
         ++nload;
     if (i >= elf_elfheader (abfd)->e_phnum && nload > 1)
       return TRUE;

I have send a patch to OpenOCD that mimics this solution in order to
be more robust and GDB consistent, but I just wanted to double-check
on the list here how these flags are handled in GNU ld, and that is
why I posted above questions.

Here are some interesting posts, just for the reference :
http://lists.gnu.org/archive/html/bug-gnu-utils/2002-02/msg00098.html
http://cygwin.com/ml/binutils/2002-09/msg00516.html
http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00319.html
http://blackfin.uclinux.org/gf/project/u-boot/tracker/?action=TrackerItemEdit&tracker_item_id=642
http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00324.html

Thanks and best regards,
Drasko

Re: ARM ELF p_paddr is not put to zero

[Ian Lance Taylor]

Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:

> On Wed, Jun 22, 2011 at 9:43 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:
>>
>>>> That is the default behaviour for the GNU tools, so that it is possible
>>>> to represent a load address separate from the virtual address.
>>> What do you exactly mean by this default behaviour ? To put p_paddr =
>>> p_vaddr ? In which situations ?
>>
>> Conceptually, every section has a virtual address (the address where the
>> section should live when the program is run) and a load address (the
>> address where the section should be loaded).  On a virtual memory
>> machine these are normally the same.  On a device without virtual memory
>> and with ROM, it is often useful to load the initialized data section at
>> one address (in ROM) but to run with the data at another address (in
>> RAM).  Given that, it becomes useful to use some mechanism for
>> representing both the load address and the virtual address in a linked
>> executable.  The GNU tools normally store the load address in the
>> p_paddr field and the virtual address in the p_vaddr field.
>
> thanks for clarifications. I think that p_vaddr can be affected with
> by --entry flag and  explicit address, as it sound logical to me that
> it is set to this value. Is this correct ? Does this flag however also
> affects p_paddr at the same time ?

With the GNU tools, unless you use a linker script with an AT clause,
p_paddr will always == p_vaddr.

> How do we specify p_paddr (I am talking about ROM and noMMU devices)?
> I.e. how do we tell at which address binary should be loaded ? Is this
> done only via linker script or there are some command line options
> with which we can define lma ?

Only via a linker script.  Well, actually, you can use objcopy
--change-section-lma.  Maybe there is some other way that I'm
forgetting.  Most people use a linker script.

> Third question is - what happens if we do not define load address at
> all, just provide address at we want to link, i.e. address of the
> first symbol (if this does not affect p_paddr just p_vaddr) ? How does
> ld manage this internally - would it equalize p_paddr to p_vaddr
> during the process and spit out binary with p_paddr = p_vaddr ?

Yes.

Ian

Re: ARM ELF p_paddr is not put to zero

[Drasko DRASKOVIC]

On Thu, Jun 23, 2011 at 12:22 AM, Ian Lance Taylor <iant@google.com> wrote:
> Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:
>> I think that p_vaddr can be affected with
>> by --entry flag and  explicit address, as it sound logical to me that
>> it is set to this value. Is this correct ? Does this flag however also
>> affects p_paddr at the same time ?
>
> With the GNU tools, unless you use a linker script with an AT clause,
> p_paddr will always == p_vaddr.
>
>> How do we specify p_paddr (I am talking about ROM and noMMU devices)?
>> I.e. how do we tell at which address binary should be loaded ? Is this
>> done only via linker script or there are some command line options
>> with which we can define lma ?
>
> Only via a linker script.  Well, actually, you can use objcopy
> --change-section-lma.  Maybe there is some other way that I'm
> forgetting.  Most people use a linker script.
>
>> Third question is - what happens if we do not define load address at
>> all, just provide address at we want to link, i.e. address of the
>> first symbol (if this does not affect p_paddr just p_vaddr) ? How does
>> ld manage this internally - would it equalize p_paddr to p_vaddr
>> during the process and spit out binary with p_paddr = p_vaddr ?
>
> Yes.

Hi Ian,
cool.

Thanks very much for these clarifications.

BR,
Drasko