Set sh_offset for .tbss sections to their nominal offset after aligning.
They are not loaded from disk so the value doesn't really matter, except
when the .tbss section is the first one in a PT_TLS segment. In that
case, it sets the p_offset for the PT_TLS segment, which according to
the ELF gABI ought to satisfy p_offset % p_align == p_vaddr % p_align.
bfd/
PR ld/32896
* elf.c (assign_file_positions_for_load_sections): Properly set
sh_offset for .tbss sections.
ld/
PR ld/32896
* testsuite/ld-elf/tbss4.d: New file.
* testsuite/ld-elf/tbss4.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
.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.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Alan Modra <amodra@gmail.com>
Approved-By: Luis Machado <luis.machado@arm.com>
This fixes an inconsistency in the linker map file, where string merge
sections (other than the first) kept their sizes. String merge
sections of like entsize all are accounted in the fisrt string merge
section size.
* ldlang.c (print_input_section): Print SEC_EXCLUDE section size
as zero.
While commit ef6379e16d ("Set the default DLL chracteristics to 0 for
Cygwin based targets") tried to undo the too broad earlier 514b4e191d
("Change the default characteristics of DLLs built by the linker to more
secure settings"), it didn't go quite far enough. Apparently the
assumption was that if it's not MinGW, it must be Cygwin. Whether it
really is okay to default three of the flags to non-zero on MinGW also
remains unclear - sadly neither of the commits came with any description
whatsoever. (Documentation also wasn't updated to indicate the restored
default.)
Setting effectively any of the DLL characteristics flags depends on
properties of the binary being linked. While defaulting to "more secure"
is a fair goal, it's only the programmer who can know whether their code
is actually compatible with the respective settings. On the assumption
that the change of defaults was indeed deliberate (and justifiable) for
MinGW, limit them to just that. In particular, don't default any of the
flags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At
least the mere applicability of the high-entropy-VA bit is pretty
questionable there in the first place - UEFI applications, after all,
run in "physical mode", i.e. either unpaged or (where paging is a
requirement, like for x86-64) direct-mapped.
The situation is particularly problematic with NX-compat: Many UEFI
implementations respect the "physical mode" property, where permissions
can't be enforced anyway. Some, like reportedly OVMF, even have a build
option to behave either way. Hence successfully testing a UEFI binary on
any number of systems does not guarantee it won't crash elsewhere if the
flag is wrongly set.
Get rid of excess semicolons as well.
commit 2707d55e53
Author: Michael Matz <matz@suse.de>
Date: Mon Mar 31 15:57:08 2025 +0200
skipped the LTO archive member even when the earlier item is also an
archive. Instead, skip the LTO archive member only if the earlier item
is a shared library.
bfd/
PR ld/32846
PR ld/32854
* elflink.c (elf_link_add_archive_symbols): Skip the LTO archive
member only if the earlier item is a shared library.
ld/
PR ld/32846
PR ld/32854
* testsuite/ld-plugin/lto.exp: Run ld/32846 test.
* testsuite/ld-plugin/pr32846a.c: New file.
* testsuite/ld-plugin/pr32846b.c: Likewise.
* testsuite/ld-plugin/pr32846c.c: Likewise.
* testsuite/ld-plugin/pr32846d.c: Likewise.
* testsuite/ld-plugin/pr32846e.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
when a shared library defines 'foo@@FOO' (default version),
a static archive defines 'foo', the shared lib comes in front
of the archive and under effect of --as-needed, and the requesting
object file uses LTO, then the link editor was wrongly including
the definition from the static archive. It must use the one
from the shared lib, like in the non-LTO or the --no-as-needed case.
See the added testcase that would wrongly print "FAIL" before
this patch.
The problem stems from several connected problems:
(1) only the decorated symbol was entered into first_hash (the hash
table designed to handle definition order in the pre-LTO-plugin
phase of the symbol table walks)
(2) in the archive symbol walk only the undecorated name would be
looked up in first_hash (and hence not found due to (1))
(3) in the archive symbol walk first_hash would only be consulted
when the linker hash table had a defined symbol. In pre-LTO
phase shared lib symbols aren't entered into the linker symbol
table.
So: add also the undecorated name into first_hash when it stems from
a default version and consult first_hash in the archive walker also
for currently undefined symbols. If it has an entry which doesn't
point to the archive, then it comes from an earlier library (shared or
static), and so _this_ archive won't provide the definition.
The need for this has disappeared with dc12032bca ("Remove m68k-aout
and m68k-coff support"); avoid the unnecessary indirection.
Sadly, with ld/pe-dll.c using the wrapper, the removal requires moving
the declaration out of libcoff.h, to properly export the underlying BFD
function.
Since 2020, mingw-w64 provides a C runtime import library variant
named "libucrtapp" too, exclude this one from autoexports like
the others.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by some of the tests. Therefore link the PDE test programs with
$NOPIE_LDFLAGS to disable PIE.
This complements commit a7eaf017f9 ("Use NOPIE_CFLAGS and
NOPIE_LDFLAGS to disable PIE").
ld/testsuite/
PR ld/21090
* ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to
disable PIE for the non-PIE versions of the test.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.
Commit 922109c718 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added
$NOPIE_CFLAGS when compiling sh1np.o and sh2np.o. It missed to add it
to mainnp.o.
ld/testsuite/
PR ld/21090
* ld-vsb/vsb.exp (visibility_test): Add support for optional
ldflags argument and use it when linking the test program.
(mainnp.o): Compile with $NOPIE_CFLAGS.
(vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS.
Fixes: 922109c718 ("Pass $NOPIE_CFLAGS to ELF visibility tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.
Commit 9d1c54ed7f ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF
tests") added $NOPIE_CFLAGS when compiling sh1np.o. It missed to add it
to sh2np.o and mainnp.o.
ld/testsuite/
PR ld/21090
* ld-shared/shared.exp (shared_test): Add support for optional
ldflags argument and use it when linking the test program.
(sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS.
(shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS.
Fixes: 9d1c54ed7f ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on
Fedora 41. The reason is that GCC on Ubuntu is configured with
--enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which causes the test to erroneously fail.
ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and
link with $NOPIE_LDFLAGS.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41
but not on Ubuntu 24.10. The reason is that GCC on Ubuntu is configured
with --enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which hides the test fail.
ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr19719 (non-PIE) with
$NOPIE_CFLAGS and link with $NOPIE_LDFLAGS.
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The suffix "defined/undefined" in the ld test pr19719 name specifies
whether weak fun() is defined or undefined is mixed up.
The test builds an executable and a shared library. The latter in two
flavors, one with weak fun() defined (libpr19719a.so, "defined") and
one without weak fun() defined (libpr19719b.so, "undefined").
The first "Run $exe fun [...]" invocation uses libpr19719b.so as
libpr19719.so, which is build from dummy.c, which does not define fun.
Thus fun is undefined during this test run.
The second "Run $exe fun [...]" invocation uses libpr19719a.so as
libpr19719.so, which is build from pr19719d.c, which does define fun.
Thus fun is defined during this test run.
Correct the test naming mix-up accordingly.
ld/testsuite/
* ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming
mix-up of when weak fun is un-/defined.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so
enable `-z relro` and related features. Make aarch64-elf match.
There is no reason to think that a "generic ELF" target should
have any particular set of features disabled.
Remove the unused pr19636-3d.d since static Position Dependent Executable
doesn't have a dynamic symbol table.
PR ld/32807
* testsuite/ld-x86-64/pr19636-3d.d: Removed.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
A GNU property section is now always generated when `-z stack-size` is
passed. This was probably introduced by GNU Property refactoring
within elfxx-aarch64.c.
When generating an ELF output file, if a note section is marked as
NOLOAD, clear the SEC_ALLOC bit so that it won't be treated as an
SHF_ALLOC section, like a .bss style section.
PR ld/32787
* ld.texi: Update NOLOAD for ELF output files.
* ldlang.c (lang_add_section): Clear the SEC_ALLOC bit for NOLOAD
note sections for ELF output files.
* testsuite/ld-elf/pr32787.d: New file.
* testsuite/ld-elf/pr32787.t: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Quite a few constructs where unconditional when they should take
$RELOCATING into account. The original observation was that output of
"ld -r" had .text start at 0x00100000.
1. Skip targets which don't support the .bss section alignment, 1 << 16.
2. Replace .bss with ".section .bss".
3. Use ".zero 0xb60000" for targets which pad the section to its alignment.
PR ld/25237
* testsuite/ld-elf/pr25237.d: Skip avr-*-* and h8300-*-*.
Update expected segment size to 0xb60000.
* testsuite/ld-elf/pr25237.s: Use ".section .bss" and
".zero 0xb60000".
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Pass -Wl,-z,lazy to compiler for i386 tests which require lazy binding
to support compilers which default to non-lazy binding.
PR ld/32762
* testsuite/ld-i386/i386.exp: Pass -Wl,-z,lazy for
"Build ifunc-1a with PIE -z ibtplt" test.
* testsuite/ld-i386/no-plt.exp: Pass -Wl,-z,lazy for
"Build libno-plt-1b.so", "No PLT (dynamic 1a)",
"No PLT (dynamic 1b)", "No PLT (dynamic 1c)",
"No PLT (PIE 1e)", "No PLT (PIE 1f)", "No PLT (PIE 1g)" tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Those tests were generated by a linker having "-z separate-code" on by
default. However, being controlled by a configure option, it can be off
by default. Forcing the option as part of the tests ensures clean
results in both cases.
tic4x-coff and mcore-pe tickle this bug by a peculiarity of their
default ld scripts.
PR 32731
* ldlang.c (lang_add_wild): Init filenames_reversed when no
filespec.
The ELF linker rejects use of this reloc type without a base register
for PIC code. Suppress its use by gas in such cases.
To keep things building for non-ELF, include the entire containing if()
in an #ifdef: All consumers of ->fx_tcbit* live in such conditionals as
well, hence there's no reason to keep the producer active.
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.
Just like was done recently for x86-64 (commit 4998f9ea9d): Even if
the assembler avoids using the relaxable relocation for inapplicable
insns, the relocation type can still appear for other reasons. Be more
thorough in the opcode checking we do, to avoid bogusly altering other
insns.
Furthermore correct an opcode mask (even if with the added condition
that's now fully benign).
--disable-default-stack is an alias for --enable-default-execstack=no.
The existing check only looked for the latter config option.
PR 32715
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Look
in config.h for result of --enable-default-execstack.
Without
commit 230a788eb2
Author: Alan Modra <amodra@gmail.com>
Date: Tue Feb 18 08:54:06 2025 +1030
PR32690, assertion failure in lang_size_relro_segment
this test triggers the linker error:
.../ld: internal error .../ld/ldlang.c 6618
collect2: error: ld returned 1 exit status
with GCC 10 or above on x86-64.
PR ld/32690
* testsuite/ld-elf/elf.exp: Run PR ld/32690 tests.
* testsuite/ld-elf/pr32690.h: New file.
* testsuite/ld-elf/pr32690a.c: Likewise.
* testsuite/ld-elf/pr32690b.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Commit 8d97c1a53f 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.
The -taso switch was quite useful 25 years ago for porting 32-bit
code with broken integer-pointer casting. Not anymore. The EF_ALPHA_32BIT
Linux support is going to be dropped in kernel v6.14 [1], NetBSD and OpenBSD
never had it, so there is no point in keeping the -taso option around.
Also remove alpha special case that uses -taso from gdb.base/dump.exp
in gdb testsuite.
[1] https://lore.kernel.org/all/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org
Signed-off-by: Ivan Kokshaysky <ink@unseen.parts>
Reviewed-By: Maciej W. Rozycki <macro@orcam.me.uk>
Approved-By: Andrew Burgess <aburgess@redhat.com>
GCC testsuite gcc.dg/20050321-2.c hit link errors on undefined
_GLOBAL_OFFSET_TABLE_. The compiler output referenced only
_GLOBAL_OFFSET_TABLE_-offsets to set it up, and to compute the
GOT-relative address of local symbols, none of which triggered the
machinery that enabled the creation of the dynamic section, so
_GLOBAL_OFFSET_TABLE_ ended up undefined.
Enable the dynamic section if we find a relocation involving
_GLOBAL_OFFSET_TABLE_. While at that, optimize checks for references
to it.
for bfd/ChangeLog
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Check for
_GLOBAL_OFFSET_TABLE_ references early, then compare hashed
symbols instead of strings.
(_bfd_sparc_elf_relocate_section): Compare hashed symbols.
for ld/ChangeLog
* testsuite/ld-sparc/got-def.s: New test.
* testsuite/ld-sparc/sparc.exp: Add it.
