| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case
of targets with only RELA support, where nevertheless object files using
REL exist. In particular objcopy will create such objects for x86-64
when converting from an i?86 ELF object (this by itself probably isn't
quite right, but we ought to cope with what our own tools are doing).
Restore the fallback to the RELA lookup, just without re-introducing the
blind NULL de-ref that was there before.
|
|
|
|
Both of these targets extend elf_link_hash_entry, so arguably should
set hash_table_id to something other than GENERIC_ELF_DATA. The patch
also sorts enum elf_target_id.
|
|
This is another case where the proper object_id can be read from
elf_backend_data.
|
|
hash_table_id can be set from elf_backend_data, now that all targets
have matching ELF_TARGET_ID and hash_table_init target_id.
|
|
aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that.
These are all targets that use other than GENERIC_ELF_DATA in their
object and hash table ids.
* elf32-am33lin.c,
* elf32-csky.c,
* elf64-ia64-vms.c,
* elf64-sparc.c,
* elfnn-aarch64.c,
* elfnn-kvx.c (ELF_TARGET_ID): Define.
|
|
|
|
elflink.c checks elf_object_id(ibfd) == elf_hash_table_id(hash_table)
in a number of places. Make them match.
|
|
|
|
Add an assertion that verifies we have filled the mdata->sections
array in bfd_mach_o_flatten_sections.
|
|
These targets currently use GENERIC_ELF_DATA as their target_id, but
that isn't exactly correct. While their bfd tdata is generic elf,
their elf_section_data is extended with extra target data. Add
MMIX_ELF_DATA and SCORE_ELF_DATA.
|
|
aout_section_data->relocs isn't set by anything, so delete it.
|
|
Nowhere in the aarch64 backend is the list created by this function
examined, and in any case there are much simpler ways to determine the
type of elf_section_data attached to a bfd ELF section. It will
always be according to the target_id of the section owner.
Delete sections_with_aarch64_elf_section_data and everything
associated with it.
|
|
Any _new_section_hook that is not itself called from another
_new_section_hook will always see used_by_bfd NULL. Remove those
NULL checks in such hooks, and tidy code a little.
|
|
|
|
In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and
instead put the gas modification of bfd's *ABS* and *UND* sections in
bfd_make_section_old_way. More recently in commit 8b5a21249537 I made
tekhex symbol creation use bfd_make_section_old_way for symbol
sections. After that we saw numerous non-repeatable oss-fuzz reports
of accesses to freed memory involving relocation symbols. I think
what is happening is:
A tekhex testcase with an absolute symbol is run through the tool,
modifying bfd_abs_section.symbol to point to a symbol on the bfd's
objalloc memory. On closing that bfd bfd_abs_section.symbol points to
freed memory.
A second testcase is run through the tool with some access to the
*ABS* symbol. This triggers the invalid memory access.
The same thing could happen if a user runs objdump or nm with two
files on the command line, the first being a tekhex file with absolute
symbols, or if ld is given tekhex input among other files. Clearly,
it's a bad idea to modify the *ABS* or *UND* sections for input files.
bfd/
* section.c (bfd_make_section_old_way): Don't call
_new_section_hook for standard abs, com, und and ind sections.
gas/
* as.c (bfd_std_section_init): New function.
(perform_an_assembly_pass): Move section initialisation to..
(gas_init): ..here. Use bfd_std_section_init.
|
|
|
|
This field is always set to point to asection.symbol, and no code ever
changes it from its initial value. With one exception. elfxx-mips.c
creates two sections with separate pointers to their symbols, and uses
those as asection.symbol_ptr_ptr. Those pointers aren't modified,
so they disappear in this patch too.
|
|
|
|
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Use
.tdata and .tbss section symbols.
(xcoff_create_ldrel): Abort on h and hsec both NULL.
|
|
This adds a sanity check to relocation symbol indices, and tidies code
a little.
The patch does result in a couple of testsuite failures
rs6000-aix7.2 +FAIL: TLS relocations (32-bit)
rs6000-aix7.2 +FAIL: TLS relocations (64-bit)
That seems reasonable to me, because prior to this patch l_symndx was
being set to -1 and -2 for .tdata and .tbss symbols resulting in a
buffer overflow when accessing the syms array.
bfd/
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Prevent
symbol array overflow on invalid relocation symbol index.
Tidy code for relocs against standard sections.
(xcoff_create_ldrel): Remove cast.
include/
* coff/xcoff.h (struct internal_ldrel): Make l_symndx uint32_t.
Make l_rtype and l_rsecnm int16_t.
|
|
_bfd_coff_free_cached_info should always call
_bfd_generic_bfd_free_cached_info, even if _bfd_coff_free_symbols
returns an error. (It won't return an error here, but let's not leave
anyone wondering about _bfd_coff_free_cached_info.)
* coffgen.c (_bfd_coff_free_cached_info): Ignore return status
of _bfd_coff_free_symbols.
|
|
|
|
BFD's threading approach is that global variables are guarded by a
lock. However, while implementing this, I missed _bfd_section_id. A
user pointed out, via Thread Sanitizier, that this causes a data race
when gdb's background DWARF reader is enabled.
This patch fixes the problem by using the BFD lock in most of the
appropriate spots. However, in ppc64_elf_setup_section_lists I chose
to simply assert that multiple threads are not in use instead. (Not
totally sure if this is good, but I don't think this can be called by
gdb.)
I chose locking in bfd_check_format_matches, even though it is a
relatively big hammer, because it seemed like the most principled
approach, and anyway if this causes severe contention we can always
revisit the decision. Also this approach means we don't need to add
configury to check for _Atomic, or figure out whether bfd_section_init
can be reworded to make "rollback" unnecessary.
I couldn't reproduce these data races but the original reporter tested
the patch and confirms that it helps.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713
|
|
Update bfd/dwarf2.c with the post DWARF5 language codes which
were added after DWARF5 was finalized. Adding them makes it
possible to return the mangling style for the new language
codes for Ada 2005 Fortran, C++, C and Assembly.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Jan Beulich <jbeulich@suse.com>
|
|
Commit fc1cfaa5f1 and bc110b6e40 were made to avoid testsuite
regressions on a number of targets that used bfd id in symbol hashing.
Since it no longer seems necessary to start plugin bfd id's from -1
and count down, revert the functional changes in those patches.
|
|
Using a bfd pointer to validate the cache isn't very robust. If a bfd
is closed somehow without clearing the cache, then it's possible that
another bfd is opened using the same memory and thus orig_bfd compares
equal to the new bfd.
* dwarf2.c (struct dwarf2_debug): Add orig_bfd_id. Delete
orig_bfd.
(_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id.
|
|
The aout object_p function copies any existing tdata. Apparently this
was done for hp300, an old target that is no longer supported. See
commit ebd241352942. This isn't useful for current sources, nor is it
necessary or useful any more to preserve tdata in object_p functions
when a target doesn't match. When I was fixing this, I noticed some
object_p functions rudely didn't release memory on failures, and
others had nits in the bfd_error returns.
* aoutx.h (some_aout_object_p): Don't restore previous tdata
on failure. Don't copy any existing tdata.
* archive.c (bfd_generic_archive_p): Don't restore previous
tdata on failure.
* pdp11.c (some_aout_object_p): Likewise.
* coff-rs6000.c (_bfd_xcoff_archive_p): Allocate both artdata
and extension in one call. Don't restore previous tdata on
failure.
* coff64-rs6000.c (xcoff64_archive_p): Likewise.
* coffgen.c (coff_real_object_p): Don't restore previous
tdata on failure.
* ihex.c (ihex_object_p): Likewise. Simplify release of tdata
on scan failure.
* mach-o.c (bfd_mach_o_scan): Don't set tdata here. Do set
error on read_command failure.
(bfd_mach_o_header_p): Set tdata here, release on failure.
Tidy bfd_error return values.
(bfd_mach_o_fat_archive_p): Tidy error return values.
* mmo.c (mmo_mkobject): Do not test current tdata.
* pef.c (bfd_pef_scan_start_address): Set bfd_error on
failure.
(bfd_pef_scan): Don't set tdata here.
(bfd_pef_object_p): Set tdata here, release on failure. Tidy
bfd_error return values.
(bfd_pef_xlib_object_p): Tidy bfd_error return values.
* srec.c (srec_object_p): Don't restore previous tdata on
failure. Do release tdata on failure.
(symbolsrec_object_p): Likewise.
* tekhex.c (tekhex_object_p): Don't ignore tekhex_mkobject
failure. Release tdata on failure.
* vms-alpha.c (alpha_vms_object_p): Don't restore previous
tdata on failure. Simplify release of tdata.
* xsym.c (bfd_sym_scan): Don't set tdata here.
(bfd_sym_object_p): Set tdata here. Release on failure.
|
|
|
|
|
|
As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1),
LoongArch machines are not limited in page size choices, and currently
page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux.
While 16KiB is the most common, the current BFD code says it is the
maximum; this is not correct, and as an effect, almost all existing
binaries are incompatible with a 64KiB kernel because the sections are
not sufficiently aligned, while being totally fine otherwise.
This is needlessly complicating integration testing [1].
This patch fixes the inconsistency, and also brings BFD behavior in line
with that of LLD [2].
[1] https://github.com/loongson-community/discussions/issues/47
[2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183
bfd/
* elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB.
(ELF_MINPAGESIZE): Define as 4KiB.
(ELF_COMMONPAGESIZE): Define as 16KiB.
ld/
* testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after
changing the target max page size to 64KiB.
* testsuite/ld-loongarch-elf/data-got.d: Likewise.
* testsuite/ld-loongarch-elf/desc-relex.d: Likewise.
* testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise.
* testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work
as intended by not checking exact instruction words.
* testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise.
Signed-off-by: WANG Xuerui <git@xen0n.name>
|
|
|
|
|
|
|
|
|
|
For default linker script, if a symbol's value outsides the bounds of the
defined section, then it may cross the data segment alignment, so we should
reserve more size about MAXPAGESIZE and COMMONPAGESIZE when doing gp
relaxations. Otherwise we may meet the truncated errors since the data
segment alignment might move the section forward.
bfd/
PR 27566
* elfnn-riscv.c (_bfd_riscv_relax_lui): Consider MAXPAGESIZE and
COMMONPAGESIZE if the symbol's value outsides the bounds of the
defined section.
(_bfd_riscv_relax_pc): Likewise.
ld/
PR 27566
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-data-segment-align*: New testcase
for pr27566. Without this patch, the rv32 binutils will meet
truncated errors for this testcase.
|
|
|
|
|
|
|
|
|
|
The undefweak symbol value of non-default visibility is 0 and does
not use plt entry, and will not be relocated in the relocate_secion
function. As a result, an infinite loop is generated because
bl %plt(sym) => bl 0.
Fix this by converting the call into a jump address 0.
|
|
|
|
This patch adds support for Guarded Control Stack in AArch64 linker.
This patch implements the following:
1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in
GNU_PROPERTY_AARCH64_FEATURE_1_AND macro.
2) Adds readelf support to read and print the GCS feature in GNU
properties in AArch64.
Displaying notes found in: .note.gnu.property
[ ]+Owner[ ]+Data size[ ]+Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: GCS
3) Adds support for the "-z gcs" linker option and document all the values
allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is
equivalent to "-z gcs=always". When '-z gcs' option is omitted from the
command line, it defaults to "implicit" and relies on the GCS feature
marking in GNU properties.
4) Adds support for the "-z gcs-report" linker option and document all the
values allowed with this option (-z gcs-report[=none|warning|error]) where
"-z gcs-report" is equivalent to "-z gcs-report=warning". When this option
is omitted from the command line, it defaults to "warning".
The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU
property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and
can be found in [1].
[1] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst
Co-authored-by: Matthieu Longo <matthieu.longo@arm.com>
Co-authored-by: Yury Khrustalev <yury.khrustalev@arm.com>
|
|
The previous message for missing BTI feature in GNU properties was
not very clear. The new message explains that a missing GNU property
marking is lacking on this specific input.
|
|
This patch attempts to make the linker output more friendly for the
developers by limiting the number of emitted warning/error messages
related to BTI issues.
Every time an error/warning related to BTI is emitted, the logger
also increments the BTI issues counter. A batch of errors/warnings is
limited to a maximum of 20 explicit errors/warnings. At the end of
the merge, a summary of the total of errors/warning is given if the
number exceeds the limit of 20 invidual messages.
|
|
The current implementation of searching the first input BFD with GNU
properties has a bug. The search was not filtering on object inputs
belonging to the output link unit only, but was also including dynamic
objects, BFD plugins, and linker-created files.
This means that the initial initialization of the output properties
were skewed, and warnings on input files that should have been emitted
were not.
This patch fixes the filtering to exclude the object input files not
belonging to the output link unit, not having the same ELF class, and
not the same target architecture.
|
|
There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties
that is enabled when the output link unit is relocatable, i.e. ld
generates an output file that can in turn serve as input to ld. (see
ld manual, -r,--relocatable for more details).
At this stage, the GNU properties have already been merged and errors
or warnings (if any) have already been issued. However, OUTPROP has
not been updated yet.
Not updating OUTPROP means that implicits enablement of BTI PLTs via
the GNU properties will be ignored for final links. Indeed, the
enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries
by looking up at gnu_property_aarch64_feature_1_and (OUTPROP).
Since the final link does not happen in the case of partial linking,
the behaviour with or without the early exit should be the same.
Given that there is currently no comment for explain why the exit is
there, and that there might in the future be cases were these properties
affect relocatable links, it is preferrable to drop the early exit.
|
|
Use _bfd_aarch64_elf_check_bti_report to report any BTI issue on the
first input object.
|
|
Move the code related to the creation of the gnu.note section to a
separate function: _bfd_aarch64_elf_create_gnu_property_section
|
|
Move the code related to the search of the first bfd input with GNU
properties to a separate function:
_bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property
|
