This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
GNU LD and ARM ELF spec disagree about meaning of p_vaddr field
- From: Nick Clifton <nickc at redhat dot com>
- To: linux-arm-kernel at lists dot arm dot linux dot org dot uk
- Cc: binutils at sources dot redhat dot com, a dot bocaniciu at computer dot org, rearnshaw at cambridge dot arm dot com, Philip dot Blundell at pobox dot com
- Date: 24 Sep 2002 17:00:03 +0100
- Subject: GNU LD and ARM ELF spec disagree about meaning of p_vaddr field
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