BFD 2.13 ELF support for LMA != VMA is non-standard

[Adrian Bocaniciu]

    This is a follow-up of my previous message where
I have reported that arm-elf-ld generates wrong
ELF program headers.

    After looking in bfd/elf.c, I have stopped wandering why
it does not work, now I wonder how it has ever worked.

    In my opinion, BFD does not conform in its interpretation
of the ELF program headers with the ELF specification.

    It certainly does not conform with any ELF document
that I happened to read and it does not conform with at least
some third party tools, e.g. the ARM Ltd. development
tools.

    The problem is with the use of the execution address of
a section and with the load address of a section, named
"vma" and "lma" in the GNU tools.

    I believe that the choice of the name "vma" was extremely
unfortunate because there is absolutely no relationship
with the notion of "Virtual Memory".  A much better name
would have been "xma", from "eXecution Memory Address".

    Probably this poor choice of a name is the origin for the
misuse of the fields "p_vaddr" and "p_paddr" of the ELF
program headers.  The current BFD code identifies
these fields with the "vma" and the "lma" of the sections.

    This is wrong.  An ELF file has a linking view, which
is described by the section headers.  The section headers
have a member "sh_addr", which is the execution address
of that section.  "sh_addr" should be identified with the
"vma" of binutils.  The value of the "sh_addr" member
is the value that must be used by the linker for computing
relocations and for satisfying the cross-references from
the file.  The link-editor does not need or use the program
headers for generating absolute code.

    An ELF file has also a loading view, which is described
by the program headers.  The loading view is used by program
loaders or debuggers and they do not need or use the information
from the section headers (for loading and running the program;
for displaying symbols, sources, etc. the section headers are still
needed).

    The two members "p_vaddr" and "p_paddr" of the program
headers have the same meaning, they refer to the load address
of a segment, i.e. the "lma" of binutils.  There are two values
for the case where an address-translating MMU is used and
there is a reason to specify in the file both the virtual value
of the load address and its translated physical value.

    If no address translation is used, than "p_vaddr"
should be equal to "p_paddr".

    Actually, in most cases the member "p_paddr" is not needed,
so many tools ignore it on input and set it either to 0 or to
"p_vaddr" on output.

    Instead of the correct behaviour, which is to set either 
"p_vaddr" or both members to "lma", BFD sets "p_vaddr"
to "vma", which is illogical and can prevent interoperability
with other tools which observe the ELF specification.

    This problem has probably not been reported before,
because if you use only tools based on the BFD
library, this bug will not manifest itself, the trouble
begins only when you must use a mixed set of tools.


    For the moment I have changed one letter in the file
"bfd/elf.c" and using the patched arm-elf-ld I obtained
an executable file that I can finally load in a debugger.

    However, since this change has been done after
only ten minutes of source browsing, it cannot be
recommended as a general patch yet.  It is probably
necessary to do much more changes for obtaining
a correct behaviour in all cases when "lma" != "vma".

    Moreover I have no idea if there exist any current
applications that use the BFD library and depend
on finding the execution address in the "p_vaddr"
member instead of the load address, so they might be broken
by an executable file generated by a patched BFD.

    In order to understand these implications I must
study much more of the BFD sources.

    Regarding the other bug that I have reported earlier,
i.e. that arm-elf-ld generates extra program headers
that may corrupt the target memory, that will require
probably much more time for determining its cause,
it might be related to the fact that my script file
uses overlays and they might confuse the linker.

                                Best regards!