bfd: correct relocation handling for objcopy COFF -> ELF
authorJan Beulich <jbeulich@suse.com>
Fri, 25 Aug 2023 12:56:44 +0000 (14:56 +0200)
committerJan Beulich <jbeulich@suse.com>
Fri, 25 Aug 2023 12:56:44 +0000 (14:56 +0200)
commit67694446f772ae95d330419eb6d01e38e6d24612
tree21119de766ad7554bd06371b5713ab4f58917c96
parent183440b0aa1cd752c324a2f4c16a620bd938d9ad
bfd: correct relocation handling for objcopy COFF -> ELF

While documented to not be reliable, it is still odd for objcopy to
silently produce bad output when converting COFF/PE object files to ELF
ones. The issue there is that relocation addends all are screwed up by
subtracting the symbol's section offset. In the COFF/PE world, to my
knowledge, section contents stores the addends alone, not the result of
symbol value plus addend. Hence the compensation talked about in a
comment ahead of the sole use site of CALC_ADDEND() may need to account
for the VMA (which is always zero for object files anyway), but not for
the symbol value.

The coff-sh.c adjustment is based upon guessing that behavior there is
the same. Note also how coff-aarch64.c short-circuits CALC_ADDEND()
altogether, which may suggest that a much simpler macro might do for the
COFF_WITH_PE case in the three arch-specific files touched here.

For (at least) Arm/WinCE this actually results in more appropriate
objdump output as well, as can be seen in the one testcase which has its
expectations adjusted (the generated binary doesn't change).
bfd/coff-i386.c
bfd/coff-sh.c
bfd/coff-x86_64.c
bfd/coffcode.h
gas/testsuite/gas/arm/wince.d