arm-elf-ld 2.13 & objcopy generate wrong ELF program headers

[Adrian Bocaniciu]

    arm-elf-ld, at least the versions 2.12.1 and 2.13, generates
sometimes (or always) wrong ELF headers.

    I did not have the time yet to investigate this problem
but it does not seem to be a problem specific only for this
target.

    I have attached an archive with three files, the linker script,
"arm-elf.ld", the ouput of readelf run on the linker output
"ld-elf.txt" and the output of readelf run on the file modified
by arm-elf-objcopy, "oc-elf.txt".

    As it can be seen in "arm-elf.ld" and "ld-elf.txt", there are
three loadable sections with these attributes:

shared_mem,        exec_addr = 02000000, file_offs = 008000, length = 0003dc
en_internal_mem,  exec_addr =  01000000, file_offs = 010000, length = 000648
wl_internal_mem,  exec_addr =  01000000, file_offs = 020000, length = 000390

The last two sections are overlaid at execution time.

arm-elf-ld should have generated three program headers having
load_address = 0x02000000 for shared_mem,
load_address = 0x020003dc for en_internal_mem,
load_address = 0x02000a24 for wl_internal_mem.

arm-elf-ld has indeed generated these 3 program headers, but
it has put the load address only in the "PhysAddr" field
and it has put the execution address in the "VirtAddr" field.

This is wrong, it must put the load address in both fields,
both in "VirtAddr" and in "PhysAddr".  These fields
both refer to the load address, the execution address
is in the section header, not in the program header.

This is especially annoying because the ARM debuggers
use only the "VirtAddr" field and ignore the "PhysAddr"
field, so that the files generated by arm-elf-ld are
unusable.

Moreover, there is a second problem in the program
headers, there are two extra program headers that
should not have existed, in the first and in the fourth
positions.  The fourth program header is not
damaging, because it corresponds with a section
of zero length ("zi_shared_mem").  It should have been
suppressed, but it does not hurt.

However the first program header is a mystery,
I cannot figure which section caused its appearance,
and it can destroy some memory in the target computer
since it has a non-zero size.

An attempt to fix the file with arm-elf-objcopy
has failed in an ugly way.  The command

arm-elf-objcopy --change-section-lma en_internal_mem=0x020003dc

has given the result seen in the file "oc-elf.txt".

The first extraneous program header has been deleted.
It should not have been missed by anyone, however also
the program header for "en_internal_mem" that I attempted
to change has been deleted instead of having its load address
altered.

Therefore objcopy has destroyed the executable file.

Another, less important bug is that the "Section
to Segment mapping" information displayed
by readelf is sometimes incorrect, as it
can be seen in "ld-elf.txt".

When I will have time, I will try to identify in the sources
the origin of these problems, however, for the moment
I had to signal them, since they make binutils unusable
for this target.

                                    Best regards!

elf-bug.zip
Description: Zip compressed data