Re: GNU LD and ARM ELF spec disagree about meaning of p_vaddr field

[Richard Earnshaw <rearnsha at arm dot com>]

I don't think this should affect ARM Linux (or NetBSD) or any other 
virtually-addressed application that runs in "USER" mode, since in all 
these cases the execution address is the same as the load address (both 
are virtual addresses).  What it might affect is booting the kernel 
itself, since in that case the kernel is loaded before the MMU is enabled, 
so it must be loaded at the physical addresses, but linked for execution 
at the virtual addresses.

However, loading kernels is often somewhat machine specific anyway, and so 
it is common to have to diddle with the image generated by the linker to 
produce something that the firmware can load.  So I doubt that would be a 
fundamental stumbling block.

R.

> Hi Guys,
> 
>   A recent posting by Adrian Bocaniciu to the bug binutils list has
>   raised an issue with GNU linker which may have important
>   repercussions for ARM Linux:
> 
>     http://sources.redhat.com/ml/bug-binutils/2002-q3/msg00388.html
> 
>   The problem is that GNU LD chooses to interpret the p_vaddr field of
>   the program header structure as being the run-time-memory-address
>   (or VMA in BFD terms) and the p_addr field as being the load-time-
>   memory-address (or LMA).  This is contrary to the ARM ELF spec.
> 
>   The ELF spec is not exactly clear about the use of these fields:
> 
>     p_vaddr    This member gives the virtual address at which the
>                first byte of the segment resides in memory.
> 
>     p_paddr    On systems for which physical addressing is relevant, 
>                this member is reserved for the segment's physical
>                address. This member requires operating system specific  
>                information.
> 
>   It is not clear when the spec says "first byte of the segment
>   resides in memory" whether it means the address at the time that the
>   segment is loaded or at the time when the segment is connected to an
>   executing process.
> 
>   (Note - it is possible to glean such information from the section
>   headers, however the ELF spec allows the section headers to be
>   optional in executables, so loaders cannot rely upon them being
>   present).
> 
>   Anyway, the ARM ELF spec requires that the p_vaddr field be
>   interpreted as the load address not the execute address:
> 
>     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.
> 
>   Current versions of the GNU binutils do not conform to this spec.
> 
>   If the GNU Linker were to be changed to conform to the ARM ELF spec,
>   would this affect ARM Linux ?
> 
>   I think that there are several possibilities:
> 
>     * If ARM Linux does not use overlays and does not examine the
>       p_paddr field then the proposed change will have no affect on it.
> 
>     * A linker command switch could be added to control the
>       interpretation of the p_vaddr and p_paddr fields.
> 
>     * A new ARM target triple could be created which does conform to
>       the ARM ELF spec.  (eg arm-elf-eabi ?)
> 
>     * The ARM Linux loader could be enhanced to look at the section
>       headers if they are present in the file.  (They almost certainly
>       will be).  It could glean the load and execute addresses from
>       there and just use the program headers as a general guide to
>       allocating memory for the process.  If the section headers are
>       absent then it could fall back to the program headers, and if
>       the p_paddr field is 0 it would know that the header conforms to
>       the ARM ELF spec and if it is nonzero then it would know that
>       the header conforms to the current binutils implementation.
> 
>   I would appreciate any comments on this issue.  Please include the
>   binutils mailing list address in your To: or Cc: field as I am not
>   subscribed to the ARM Linux mailing list.
> 
> Cheers
>         Nick
>