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

[Nick Clifton <nickc at redhat dot com>]

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