| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
The fix for 64-bit BFD detection omitted the regeneration of a bunch
of configury files; fix that.
|
|
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 1d5269c994bf
("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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tidy early out errors which didn't free matching_vector. Don't
bfd_preserve_restore if we get to err_ret from the first
bfd_preserve_save, which might fail from a memory allocation leaving
preserve.marker NULL. Also take bfd_lock a little earlier before
modifying abfd->format to simplify error return path from a lock
failure.
|
|
|
|
|
|
|
|
Fixes [1]. Previously iteration over GNU properties of an input file
could stop before reaching GNU_PROPERTY_AARCH64_FEATURE_1_AND which
would result in incorrect inference of properties of the output file.
In the particular use case described in [1], the memory seal property
GNU_PROPERTY_MEMORY_SEAL with number 3, if present in the input file,
prevented reading information from GNU_PROPERTY_AARCH64_FEATURE_1_AND
property due to filtering by property number.
[1] PR32818 https://sourceware.org/bugzilla/show_bug.cgi?id=32818
|
|
|
|
|
|
|
|
There's no reason not to do as the comment says, just like all other
architectures do when they need custom field: Call the allocation method
of the "superclass". Which is the ELF one, of which in turn the BFD one
is the "superclass", dealt with accordingly by
_bfd_elf_link_hash_newfunc().
|
|
The need for this has disappeared with c65c21e1ffd1 ("various i386-aout
and i386-coff target removal"), with a few other users having got
removed just a few days earlier; avoid the unnecessary indirection.
|
|
While COFF, unlike ELF, doesn't have a generic way to express symbol
size, there is a means to do so for functions. When inputs are ELF,
propagate function sizes, including the fact that a symbol denotes a
function, to the output's symbol table.
Note that this requires hackery (cross-object-format processing) in two
places - when linking, global symbols are entered into a global hash
table, and hence relevant information needs to be updated there in that
case, while otherwise the original symbol structures can be consulted.
For the setting of ->u.syment.n_type the later writing of the field to
literal 0 needs to be dropped from coff_write_alien_symbol(). It was
redundant anyway with an earlier write of the field using C_NUL.
|
|
|
|
|
|
|
|
In PR gdb/31846 the user reported an issue where GDB is unable to find
the build-id within an ELF, despite the build-id being
present (confirmed using readelf).
The user was able to try several different builds of GDB, and in one
build they observed the warning:
warning: BFD: FILENAME: unable to decompress section .debug_info
But in may other builds of GDB this warning was missing.
There are, I think, a couple of issues that the user is running into,
but this patch is about why the above warning is often missing from
GDB's output.
I wasn't able to reproduce a corrupted .debug_info section such that
the above warning would be triggered, but it is pretty easy to patch
the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that
the call to bfd_init_section_decompress_status is reported as a
failure, thus triggering the warning. There is a patch that achieves
this in the bug report.
I did this, and can confirm that on my build of GDB, I don't see the
above warning, even though I can confirm that the _bfd_error_handler
call (in _bfd_elf_make_section_from_shdr) is being reached.
The problem is back in format.c, in bfd_check_format_matches. This
function intercepts all the warnings and places them into a
per_xvec_messages structure. These warnings are then printed with a
call to print_and_clear_messages.
If bfd_check_format_matches finds a single matching format, then
print_and_clear_messages, will print all warnings associated with that
single format.
But if no format matches, print_and_clear_messages will print all the
warnings, so long as all targets have emitted the same set of
warnings, and unfortunately, that is not the case for me.
The warnings are collected by iterating over bfd_target_vector and
trying each target. My target happens to be x86_64_elf64_vec, and, as
expected this target appears in bfd_target_vector.
However, bfd_target_vector also includes DEFAULT_VECTOR near the top.
And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me,
the x86_64_elf64_vec entry appears twice in bfd_target_vector, this
means that x86_64_elf64_vec ends up being tried twice, and, as each
try generates one warning, the x86_64_elf64_vec entry in the
per_xvec_messages structure, has two warnings, while the other
per_xvec_messages entries only have one copy of the warning.
Because of this difference, print_and_clear_messages decides not to
print any of the warnings, which is not very helpful.
I considered a few different approaches to fix this issue:
We could de-duplicate warnings in the per_xvec_messages structure as
new entries are added. So for any particular xvec, each time a new
warning arrives, if the new warning is identical to an existing
warning, then don't record it. This might be an interesting change in
the future, but for now I rejected this solution as it felt like a
bodge, the duplicate warnings aren't really from a single attempt at
an xvec, but are from two distinct attempts at the same xvec. And so:
I wondered if we could remove the duplicate entries from
bfd_target_vector. Or if we could avoid processing the same xvec
twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard
to do, but bfd_target_vector also includes SELECT_VECS, which I think
could contain more duplicates. Changing bfd_check_format_matches to
avoid attempting any duplicate vectors would now require more
complexity than a single flag, and I felt there was an easier
solution, which was:
I propose that within bfd_check_format_matches, within the loop that
tries each entry from bfd_target_vector, as we switch to each vector
in turn, we should delete any existing warnings within the
per_xvec_messages structure for the target vector we are about to try.
This means that, if we repeat a target, only the last set of warnings
will survive.
With this change in place, print_and_clear_messages now sees the same
set of warnings for each target, and so prints out the warning
message.
Additionally, while I was investigating this issue I managed to call
print_and_clear_messages twice. This caused a crash because the first
call to print_and_clear_messages frees all the associated memory, but
leaves the per_xvec_messages::next field pointing to the now
deallocated object. I'd like to propose that we set the next field to
NULL in print_and_clear_messages. This clearly isn't needed so long
as print_and_clear_messages is only called once, but (personally) I
like to set pointers back to NULL if the object they are pointing to
is free and the parent object is going to live for some additional
time. I can drop this extra change if people don't like it.
This change doesn't really "fix" PR gdb/31846, but it does mean that
the warning about being unable to decompress .debug_info should now be
printed consistently, which is a good thing.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846
Reviewed-By: Alan Modra <amodra@gmail.com>
|
|
|
|
commit 2707d55e539ef323dd14a1293e762bf3d9739ee7
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>
|
|
We missed one place where it is necessary to check for empty groups.
PR 32858
* elflink.c (elf_gc_sweep): Protect against empty group.
|
|
|
|
|
|
|
|
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.
|
|
Sanity check symbol string table offsets, and tidy structs. "long"
isn't a good choice for _l_zeroes and _l_offset since it can be 64
bits which blows out the size of the symbol struct unnecessarily.
Also, all of the sizes in internal_ldsym need only be 32 bits, but I
made them size_t because I didn't want to audit all expressions using
them for overflow.
bfd/
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_symtab): Sanity
check symbol _l_offset.
(xcoff_link_add_dynamic_symbols),
(xcoff_link_check_dynamic_ar_symbols): Likewise.
include/
* coff/xcoff.h (struct internal_ldhdr): Tidy types.
(struct internal_ldsym): Use uint32_t for _l_zeroes and _l_offset.
|
|
Much of the xcoff code is not well protected against fuzzed object file
attacks. This sanity checks some values in ".loader".
* xcofflink.c (xcoff_get_ldhdr): New function.
(_bfd_xcoff_get_dynamic_symtab_upper_bound),
(_bfd_xcoff_canonicalize_dynamic_symtab),
(_bfd_xcoff_get_dynamic_reloc_upper_bound),
(_bfd_xcoff_canonicalize_dynamic_reloc),
(xcoff_link_add_dynamic_symbols),
(xcoff_link_check_dynamic_ar_symbols): Use xcoff_get_ldhdr.
|
|
* elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Properly bounds
check relocation field.
(nds32_elf_hi20_reloc, nds32_elf_generic_reloc): Likewise.
(nds32_elf_final_link_relocate): Likewise.
|
|
Per the Microsoft PE documentation, XP and earlier on i686 require the
Size field to be 64, rather than the actual size as required on other
architectures. I have confirmed Windows 11 accepts either 64 or the
actual size for i386 images, but only the actual size for x86_64 images.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
|
|
This is filled in with the rva of _load_config_used if defined (much
like _tls_used), and the size is the first 32-bit value at that symbol.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
|
|
Rationalize the error messages in _bfd_XXi_final_link_postscript().
They now all correctly refer to DataDirectory instead of DataDictionary,
and use unified format strings, so fewer translations are needed.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
|
|
This function returns the leading char to use, so we cannot just assume
it will always be '_' or '\0'.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
|
