Re: ARM ELF p_paddr is not put to zero

[Drasko DRASKOVIC <drasko dot draskovic at gmail dot com>]

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