Jan Beulich [Wed, 11 Jun 2025 12:32:34 +0000 (14:32 +0200)]
ld/PE: special-case relocation types only for COFF inputs
In 72cd2c709779 ("ld/PE: no base relocs for section (relative) ones") I
made a pre-existing problem quite a bit worse: When looking at a
relocation's (numerical) howto->type, that value is meaningful only if
the object was of corresponding COFF type. ELF objects in particular
have their own enumeration. As it stands, specifically the not entirely
unusual R_X86_64_32 and R_X86_64_32S did no longer have relocations
emitted for them, due to matching R_AMD64_SECTION and R_AMD64_SECREL in
value respectively.
Jens Remus [Mon, 19 May 2025 08:38:01 +0000 (10:38 +0200)]
s390: Prevent GOT access rewrite for misaligned symbols
Dereferences of GOT slots with lgrl or lg for global symbols are
rewritten to larl to get get rid of the extra memory access. However
this is invalid for:
- symbols marked for absolute addressing
- symbols at odd addresses (larl can handle only even addresses)
Commit e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain
symbols") added checks for the above. But instead of checking the
address of a symbol for being halfword aligned, it tries to deduce
this from whether the symbol value and section the symbol is defined
in are halfword aligned. The way it is done has two issues:
1. The use of bfd_section_from_elf_index to obtain the section the
symbol is defined in may not return the one that remains in the
output. For instance for COMDAT sections getting deduplicated
the section retrieved using bfd_section_from_elf_index may not be
the same as h->root.u.def.section. If COMDAT sections of same
group signature have different alignment properties the wrong
one may be checked. This may then lead to an erroneous rewrite
of lgrl %rX, sym@GOTENT to larl %rX, sym, although the symbol in
the remaining section is not properly aligned, triggering an
"relocation for misaligned symbol" error at link-time.
This may for instance occur when mixing C++ modules compiled with
GCC and Clang, as GCC emits a 2-byte alignment and Clang a 1-byte
alignment for COMDAT sections containing type information:
Produces (reformatted and reduced):
File Name Off Size ES Flg Lk Inf Al
sample_gcc.o .rodata._ZTS1A 000080 000004 00 AG 0 0 2
sample_clang.o .rodata._ZTS1A 000058 000003 00 AG 0 0 1
2. The symbol may end up at an even address, if both the symbol value
and the section defining the symbol are 1-byte aligned. While this
does not trigger an error, it fails an opportunity to rewrite a GOT
access.
In a Linux Kernel build this causes ~15k GOT accesses using lgrl to
be skipped to be rewritten to larl.
Resolve both issues by simply checking whether the symbol address is
halfword aligned. Do not check the symbol value nor section defining
the symbol for halfword alignment.
bfd/
PR ld/32969
* elf64-s390.c (elf_s390_relocate_section): Only rewrite
lgrl/lg from GOT to larl if symbol address is halfword aligned.
ld/testsuite/
PR ld/32969
* ld-s390/s390.exp (pr32969_64-1, pr32969_64-2): Add tests for
rewrite of GOT access when COMDAT section deduplication is
involved.
* ld-s390/pr32969_64-1.dd: New test for rewrite of GOT access
when COMDAT section deduplication is involved.
* ld-s390/pr32969_64-2.dd: Likewise.
* ld-s390/pr32969a.s: Likewise.
* ld-s390/pr32969b.s: Likewise.
* ld-s390/pr32969c.s: Likewise.
Bug: https://sourceware.org/PR32969 Fixes: e6213e09ed0e ("S/390: Prevent GOT access rewrite for certain symbols") Reported-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
(cherry picked from commit ed53e990e57e4f98b42a57b481fc12ad7f55b42e)
x86: widen @got{,pcrel} support to PUSH and APX IMUL
With us doing the transformation to an immediate operand for MOV and
various ALU insns, there's little reason to then not support the same
conversion for the other two insns which have respective immediate
operand forms. Unfortunately for IMUL (due to the 0F opcode prefix)
there's no suitable relocation, so the pre-APX forms cannot be marked
for relaxation in the assembler.
"pushl main@GOT(%ebx)" in sysdeps/i386/start.S was assembled to
Linkers in binutils versions older than 2.45 treated it as jmp and relaxed
it to
22c: e9 cf ff ff ff jmp 200 <main>
231: 90 nop
Update elf_i386_convert_load_reloc in binutils versions older than 2.45
to check MODRM for call and jmp to work with i386 glibc assembled with
binutils 2.45 or newer. Do the same in elf_x86_64_convert_load_reloc.
PR ld/32991
* elf32-i386.c (elf_i386_convert_load_reloc): Check MODRM for
call and jmp.
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise.
H.J. Lu [Thu, 20 Mar 2025 20:16:34 +0000 (13:16 -0700)]
dwarf: Dump .debug_loclists only for DWARF-5
.debug_loclists section is loaded into debug_information as DWARF-5 debug
info and .debug_loc section is loaded into debug_information as pre-DWARF-5
debug info. When dumping .debug_loc section, we should only process
pre-DWARF-5 debug info in debug_information. When dumping .debug_loclists
section, we should only process DWARF-5 info in debug_information.
binutils/
PR binutils/32809
* dwarf.c (display_debug_loc): Dump .debug_loclists only for
DWARF-5.
ld/
PR binutils/32809
* testsuite/ld-x86-64/dwarf4.s: New file.
* testsuite/ld-x86-64/dwarf5a.s: Likewise.
* testsuite/ld-x86-64/dwarf5b.s: Likewise.
* testsuite/ld-x86-64/pr32809.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr32809.
This puts back %F into translated fatal error messages (and reverts a
few other small changes), to not disturb translation work done for the
2.44 branch.
Simon Marchi [Thu, 20 Feb 2025 15:13:38 +0000 (10:13 -0500)]
gdb/compile: add missing entry in bfd_link_callbacks array
clang 19 fails to build gdb with this error:
/home/simark/src/binutils-gdb/gdb/compile/compile-object-load.c:302:3: error: cannot initialize a member subobject of type 'void (*)(const char *, ...) __attribute__((noreturn))' with an lvalue of type 'void (const char *, ...)'
302 | link_callbacks_einfo, /* einfo */
| ^~~~~~~~~~~~~~~~~~~~
This illustrates that the bfd_link_callbacks array is missing an entry
for the "fatal" callback, add it.
The fatal field was added very recently, in d26161914 ("PR 32603, more
ld -w misbehaviour"). We're lucky that the new callback was marked with
the noreturn attribute and that clang checks that, otherwise this would
have gone unnoticed.
Alan Modra [Sun, 16 Feb 2025 13:04:55 +0000 (23:34 +1030)]
PR 32603, more ld -w misbehaviour
Commit 8d97c1a53f3d claimed to replace all einfo calls using %F with
a call to fatal. It did so only for the ld/ directory. This patch
adds a "fatal" to linker callbacks, and replaces those calls in bfd/
too.
Alan Modra [Thu, 6 Feb 2025 11:16:22 +0000 (21:46 +1030)]
PR 32603, ld -w misbehaviour
ld -w currently causes segmentation faults and other misbehaviour
since it changes einfo with %F in the format string (fatal error) to
not exit. This patch fixes that by introducing a new variant of einfo
called "fatal" that always exits, and replaces all einfo calls using
%F with a call to fatal without the %F. I considered modifying einfo
to inspect the first 2 or 4 chars in the format string, looking for
%F, but decided that was probably a bad idea given that translators
might have moved the %F. It's also a little nicer to inform the
compiler of a function that doesn't return.
The patch also fixes some formatting nits, and makes use of %pA
to print section names in a couple of places in aix.em.
projects / thirdparty / binutils-gdb.git / log
