b...@gmx.net writes:
>> The difference in the output appears to be in the strings. This
>> suggests that your compilers are behaving differently than I expect with
>> respect to references to entries in string merge sections. Can you send
>> me just the file TestClass.o? That might be enough for me to see the
>> problem.
> Yes, in the tarball below. See the directories using_*ld
Thanks for sending the object files. Now I remember. I've seen this
problem before and reported it to Intel before. They are generating
object files which do not follow the x86_64 ELF ABI. The x86_64 ELF ABI
specifies that the relocation computation for R_X86_64_32 is simply "S +
A". The ABI says:
S Represents the value of the symbol whose index resides in the
relocation entry.
A Represents the addend used to compute the value of the relocatable
field.
The AMD64 ABI architectures uses only Elf64_Rela relocation entries
with explicit addends. The r_addend member serves as the relocation
addend.
So this is all clear enough, and gas complies with it.
However, in the object file you sent me, I see this using objdump -dr:
142: ba 14 00 00 00 mov $0x14,%edx
143: R_X86_64_32 .rodata
and this using readelf -r:
000000000143 000d0000000a R_X86_64_32 0000000000000000 .rodata + 0
As you can see, the r_addend member for this relocation has the value 0.
There is a 0x14 stored in the instruction itself, but the x86_64 ELF ABI
says that that field should be ignored.
As it happens, the GNU linker does not ignore that field. It
incorrectly adds the value in the field in the instruction into the
final relocation value. (This is because the src_mask field in the
howto entry for R_X86_64_32 in bfd/elf64-x86-64.c is 0xffffffff when it
should be 0; this bug dates back to the initial creation of the file).
That is why this object file works with the GNU linker.
So the problem that gold faces is whether it should adhere to the
published ABI, or whether it should emulate the GNU linker. Adhering to
the published ABI does work correctly with output from the GNU tools.
Unfortunately, as you have discovered, the Intel tools generate
incorrect output which does not follow the ABI, and gold does not work
with them.
My preference would be for Intel to fix their tools to conform to the
published ABI. Then there will be no confusion going forward. If you
have purchased a copy of the Intel compilers, I encourage you to report
the bug. I would be happy to provide more details and arguments if
required.
Ian
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
