https://bugzilla.redhat.com/show_bug.cgi?id=2036061
Nick Clifton <nickc(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|binutils |nasm
Assignee|nickc(a)redhat.com |dominik(a)greysector.net
CC| |dominik(a)greysector.net,
| |java-sig-commits(a)lists.fedo
| |raproject.org,
| |mizdebsk(a)redhat.com,
| |pbonzini(a)redhat.com
--- Comment #4 from Nick Clifton <nickc(a)redhat.com> ---
Right - I have tracked the problem down to this commit:
2021-05-07 Jan Beulich <jbeulich(a)suse.com>
* elf64-x86-64.c (x86_64_elf_howto_table): Set src_mask fields
to zero.
Which fixed a bug in the x86 linker's handling of RELA type relocations.
These relocations are intended to have all the necessary information in
the reloc itself, and do not take any data from the instruction being
relocated. But the NASM assembler is creating RELA relocations with
additional data in the instruction itself:
% objdump -Dr hello.o
[...]
0000000000000000 <.debug_info>:
[...]
13: 00 2d 00 00 00 00 add %ch,0x0(%rip) # 19
<.debug_info+0x19>
14: R_X86_64_64 .text
What NASM wants the relocation for bytes 14..17 to do is to take the
the value stored there (0x0000002d), add in the address of the .text
section (0x00401000) and store the result back into those bytes. And
prior to the 2.37 release of the binutils this is what happened. But
now that the bug has been fixed what the relocation actually does is
to totally ignore the contents of bytes 14..17 and instead just install
the address of the start of the .text section.
Reassigning to NASM.
What needs to happen, in my opnion, is for NASM to either create REL
type relocs instead of RELA relocs, or else move the 0x0000002d value
out of the .debug_info section and into the R_X86_64_64 reloc.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2036061