Add --enable-mark-plt linker configure option to mark PLT entries with
DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by
default.
* NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt.
* config.in: Regenerated.
* configure: Likewise.
* configure.ac: Add --enable-mark-plt.
(DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED.
* emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT):
Support DEFAULT_LD_Z_MARK_PLT.
* emultempl/elf-x86.em (elf_x86_64_before_parse): New function.
(LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for
x86-64 targets.
When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and
DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation
stores the offset of the indirect branch instruction. However, glibc
versions which don't have this commit in glibc 2.36:
commit f8587a61892cbafd98ce599131bf4f103466f084
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri May 20 19:21:48 2022 -0700
x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT
According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT
and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we
can ignore their r_addends.
Reviewed-by: Fangrui Song <maskray@google.com>
won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation.
Although this commit has been backported to glibc 2.33/2.34/2.35 release
branches, it is safer to require glibc 2.36 for such binaries.
Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to
also add GLIBC_2.36 version dependency for -z mark-plt on the shared C
library if it provides a GLIBC_2.XX symbol version.
* elflink.c (elf_find_verdep_info): Moved to ...
* elf-bfd.h (elf_find_verdep_info): Here.
(elf_backend_data): Add elf_backend_add_glibc_version_dependency.
(_bfd_elf_link_add_glibc_version_dependency): New function.
(_bfd_elf_link_add_dt_relr_dependency): Likewise.
* elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency):
Likewise.
(elf_backend_add_glibc_version_dependency): New.
* elflink.c (elf_link_add_dt_relr_dependency): Renamed to ...
(elf_link_add_glibc_verneed): This. Modified to support other
glibc dependencies.
(_bfd_elf_link_add_glibc_version_dependency): Likewise.
(_bfd_elf_link_add_dt_relr_dependency): Likewise.
(bfd_elf_size_dynamic_sections): Call
elf_backend_add_glibc_version_dependency instead of
elf_link_add_dt_relr_dependency.
* elfxx-target.h (elf_backend_add_glibc_version_dependency): New.
(elfNN_bed): Add elf_backend_add_glibc_version_dependency.
ld/
* testsuite/ld-x86-64/mark-plt-1a.rd: New file.
* testsuite/ld-x86-64/mark-plt-1b.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for
GLIBC_2.36 dependency.
Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or
aarch64-unknown-gnu.
The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh,
or to aarch64linux.sh with Linux-specific logic removed; and mainly different
from the generic aarch64elf.sh in that it does not set EMBEDDED=yes.
Coupled with a corresponding GCC patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
The ld lexer converts strings to integers without overflow checking,
so I don't think there is any problem in truncating an integer that
exceeds the size of a bfd_vma rather than using (bfd_vma) -1.
PR 31120
* ldlex.l: Don't use bfd_scan_vma for integer conversion, use
strtoull.
Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
With old "medium" code model, we call a function with a pair of PCALAU12I
and JIRL instructions. The assembler produces something like:
8: 1a00000c pcalau12i $t0, 0
8: R_LARCH_PCALA_HI20 g
c: 4c000181 jirl $ra, $t0, 0
c: R_LARCH_PCALA_LO12 g
The linker generates a "PLT entry" for data without any diagnostic.
If "g" is a data symbol and ld with -shared option, it may load two
instructions in the PLT.
Without -shared option, loongarch_elf_adjust_dynamic_symbol can delete PLT
entry.
For R_LARCH_PCALA_HI20 relocation, linker only generate PLT entry for STT_FUNC
and STT_GNU_IFUNC symbols.
Add tls le relax related testsuites in ld.
The new test cases are mainly tested in three aspects:
1. tls le relax function correctness test.
2. tls le relax boundary check test.
3. tls le relax function compatibility test.
ld/testsuite/ChangeLog:
* ld/testsuite/ld-loongarch-elf/relax.exp: Modify test.
* ld/testsuite/ld-loongarch-elf/old-tls-le.s: New test.
* ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s: Likewise.
* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s: Likewise.
* ld/testsuite/ld-loongarch-elf/relax-tls-le.s: Likewise.
* ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s: Likewise.
For
add name@gottpoff(%rip), %reg
mov name@gottpoff(%rip), %reg
add
# define R_X86_64_CODE_4_GOTTPOFF 44
and for
lea name@tlsdesc(%rip), %reg
add
# define R_X86_64_CODE_4_GOTPC32_TLSDESC 45
if the instruction starts at 4 bytes before the relocation offset.
They are similar to R_X86_64_GOTTPOFF and R_X86_64_GOTPC32_TLSDESC,
respectively. Linker can covert GOTTPOFF to
add $name@tpoff, %reg
mov $name@tpoff, %reg
and GOTPC32_TLSDESC to
mov $name@tpoff, %reg
mov name@gottpoff(%rip), %reg
if the instruction is encoded with the REX2 prefix when possible.
bfd/
* elf64-x86-64.c (x86_64_elf_howto_table): Add
R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC.
(R_X86_64_standard): Updated.
(x86_64_reloc_map): Add BFD_RELOC_X86_64_CODE_4_GOTTPOFF
and BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_4_GOTTPOFF
and R_X86_64_CODE_4_GOTPC32_TLSDESC.
(elf_x86_64_tls_transition): Likewise.
(elf_x86_64_scan_relocs): Likewise.
(elf_x86_64_relocate_section): Likewise.
* reloc.c (bfd_reloc_code_real): Add
BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
* bfd-in2.h: Regenerated.
* libbfd.h: Likewise.
gas/
* config/tc-i386.c (tc_i386_fix_adjustable): Handle
BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(md_assemble): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF.
(output_insn): Don't add empty REX prefix with REX2 prefix.
(output_disp): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
(md_apply_fix): Likewise.
(i386_validate_fix): Generate BFD_RELOC_X86_64_CODE_4_GOTTPOFF or
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC if ixp->fx_tcbit3 is set.
(tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_4_GOTTPOFF and
BFD_RELOC_X86_64_CODE_4_GOTPC32_TLSDESC.
* testsuite/gas/i386/x86-64-gottpoff.d: New file.
* testsuite/gas/i386/x86-64-gottpoff.s: Likewise.
* testsuite/gas/i386/x86-64-tlsdesc.d: Likewise.
* testsuite/gas/i386/x86-64-tlsdesc.s: Likewise.
include/
* elf/x86-64.h (elf_x86_64_reloc_type): Add
R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_4_GOTPC32_TLSDESC
ld/
* testsuite/ld-x86-64/tlsbindesc.d: Updated.
* testsuite/ld-x86-64/tlsbindesc.rd: Likewise.
* testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_4_GOTTPOFF
and R_X86_64_CODE_4_GOTPC32_TLSDESC tests.
* Problematic fix commit,
2029e13917d53d2289d3ebb390c4f40bd2112d21
RISC-V: Clarify the behaviors of SET/ADD/SUB relocations
* Bugzilla,
https://sourceware.org/bugzilla/show_bug.cgi?id=31179#c5
The addend of SUB_ULEB128 should be zero if using .uleb128, but we make it
non-zero by accident in assembler before. This causes troubles by applying
the above commit, since the calculation is changed to support .reloc *SUB*
relocations with non-zero addend.
We encourage people to rebuild their stuff to get the non-zero addend of
SUB_ULEB128, but that might need some times, so report warnings to inform
people need to rebuild their stuff if --check-uleb128 is enabled.
Since the failed .reloc cases for ADD/SET/SUB/ULEB128 are rarely to use,
it may acceptable that stop supproting them until people rebuld their stuff,
maybe half-year or a year later. Or maybe we should teach people that don't
write the .reloc R_RISCV_SUB* with non-zero constant, and then report
warnings/errors in assembler.
bfd/
* elfnn-riscv.c (perform_relocation): Ignore the non-zero addend of
R_RISCV_SUB_ULEB128.
(riscv_elf_relocate_section): Report warnings to inform people need
to rebuild their stuff if --check-uleb128 is enabled. So that can
get the right non-zero addend of R_RISCV_SUB_ULEB128.
* elfxx-riscv.h (struct riscv_elf_params): Added bool check_uleb128.
ld/
* NEWS: Updated.
* emultempl/riscvelf.em: Added linker risc-v target options,
--[no-]check-uleb128, to enable/disable checking if the addend of
uleb128 is non-zero or not. So that people will know they need to
rebuild the objects with binutils 2.42 and up, to get the right zero
addend of SUB_ULEB128 relocation, or they may get troubles if using
.reloc.
* ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* ld/testsuite/ld-riscv-elf/pr31179*: New test cases.
If the symbol index is not zero, the addend is used to represent
the first and the third expressions of the .align.
The lowest 8 bits are used to represent the first expression.
Other bits are used to represent the third expression.
The addend of R_LARCH_ALIGN for ".align 5, ,4" is 0x405.
The addend of R_LARCH_ALIGN for ".balign 32, ,4" is 0x405.
GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when
the linked libraries have dependencies on shared objects themselves:
$ gcc -m32 -o ei ei.c -lexecinfo
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found
(try using -rpath or -rpath-link)
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
/usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0'
[...]
Fixed by handling FreeBSD/amd64 like Linux/x86.
Tested on amd64-pc-freebsd14.0.
When using --print-memory-usage, the printed size can be zero and in
that case, the unit should be B and not GB.
ld/
* ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
* testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
* testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
This isn't a particularly worrying memory leak, but fix it anyway.
PR 31162
* ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
Add %E to error messages.
For tail36, it is necessary to explicitly indicate the temporary register.
Therefore, the compiler and users will know that the tail will use a register.
call36 func
pcalau18i $ra, %call36(func)
jirl $ra, $ra, 0;
tail36 $t0, func
pcalau18i $t0, %call36(func)
jirl $zero, $t0, 0;
R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
these two instructions must adjacent.
The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.
The start of MEMORY region text currently starts hard-coded at 0.
The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.
For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.
If ok, please apply to master.
This one is also fine to back-port.
Johann
--
AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.
ld/
PR 31177
* scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
(MEMORY): Use as start address for the text region.
This is a small addendum to PR31124 "rodata in flash for
more AVR devices".
It adds some symbols so the startup code can set a lock
on the FLMAP bit field as specified by the user.
New symbols are introduced because otherwise, all the
computations / decisions would have to be performed at
run-time.
It approved, please apply to master.
Johann
--
ld/
PR 31124
* scripttempl/avr.sc: Adjust comments.
[MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock.
Remove __flmap_lsl4.
This reloc is meant for the 16-bit LWGP instruction, 0x6400/0xfc00
match/mask encoding in `micromips_opcodes'. It is correctly specified
to operate on a half-word by the howtos in elf32-mips.c, elfn32-mips.c
and elf64-mips.c, but is incorrectly subject to shuffle/unshuffle in
code like _bfd_mips_elf32_gprel16_reloc.
Current behaviour when applying the reloc to .byte 0x11,0x22,0x33,0x44
is to apply the reloc to byte 0x22 when big-endian, and to byte 0x33
when little-endian. Big-endian behaviour is unchanged after this
patch and little-endian correctly applies the reloc to byte 0x11.
The patch also corrects REL addend extraction from section contents,
and overflow checking. gold had all of the bfd problems with this
reloc and additionally did not apply the rightshift by two.
bfd/
* elfxx-mips.c (micromips_reloc_shuffle_p): Return false for
R_MICROMIPS_GPREL7_S2.
(mips_elf_calculate_relocation): Correct sign extension and
overflow calculation for R_MICROMIPS_GPREL7_S2.
(_bfd_mips_elf_relocate_section): Update small-data overflow
message.
gold/
* mips.cc (Mips_relocate_functions::should_shuffle_micromips_reloc):
Return false for R_MICROMIPS_GPREL7_S2.
(Mips_relocate_functions::mips_reloc_unshuffle): Update comment.
(Mips_relocate_functions::relgprel): Remove R_MICROMIPS_GPREL7_S2
handling.
(Mips_relocate_functions::relgprel7): New function.
(Target_mips::Relocate::relocate): Adjust to suit.
ld/
* testsuite/ld-mips-elf/reloc-4.d: Adjust expected error.
* testsuite/ld-mips-elf/reloc-5.d: Likewise.
aarch64-elf fails the ld-aarch64/bfd-far-3.d test, due to the stubs
being emitted in a different order to that of aarch64-linux. They are
emitted in a different order due to stub names for local symbols
having the section id in the stub name. aarch64-linux-ld generates
one more section than aarch64-elf-ld. That section is .gnu.hash. So
the stub names differ and are hashed to different slots in
stub_hash_table.
Fix this by running the test with --hash-style=sysv, and adjust
expected output. I've also changed the branch over stubs emitted at
the start of a group of stubs to not care about the symbol, for all
groups not just the one that needed changing.
* ld-aarch64/bti-far-3.d: Add --hash-style=sysv. Adjust
expected output.
commit eab996435fe65a421541f59557c5f1fd427573a3
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Nov 7 13:58:32 2023 +0100
ld/x86: reduce testsuite dependency on system object files
changed some C compiler tests to assembler/linker tests which introduced
2 problems:
1. It broke x32 binutils tests since --64 was passed to assembler, but
-m elf_x86_64 wasn't passed to linker.
2. -nostdlib was passed to C compiler driver to exclude standard run-time
files which should be avoided with -r option for linker tests.
Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for
linker tests with -r.
PR ld/30722
* testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker
for tests with --64. Remove -nostdlib for tests with -r.
The following patch attempts to use x86 SHA ISA if available to speed
up in my testing about 2.5x sha1 build-id processing (in my case on
AMD Ryzen 5 3600) while producing the same result.
I believe AArch64 has similar HW acceleration for SHA1, perhaps it
could be added similarly.
Note, seems lld uses BLAKE3 rather than md5/sha1. I think it would be
a bad idea to lie to users, if they choose --buildid=sha1, we should
be using SHA1, not some other checksum, but perhaps we could add some other
--buildid= styles and perhaps make one of the new the default.
Tested on x86_64-linux, both on Intel i9-7960X (which doesn't have
sha_ni ISA support) without/with the patch and on AMD Ryzen 5 3600
(which does have it) without/with the patch.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
include/
* sha1.h (sha1_process_bytes_fn): New typedef.
(sha1_choose_process_bytes): Declare.
libiberty/
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
and cpuid.h.
(sha1_hw_process_bytes, sha1_hw_process_block,
sha1_choose_process_bytes): New functions.
* config.in: Regenerated.
* configure: Regenerated.
ld/
* ldbuildid.c (generate_build_id): Use sha1_choose_process_bytes ()
instead of &sha1_process_bytes.
PR 31067
* linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton.
* ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave.
Previously the condition prevented shared objects from being relaxed.
To remove the limitation, we need to update program header size and
.eh_frame_hdr size before relaxation.
commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*"
changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32
this new name sorts differently when regenerating gas/config.in
commit e922d1eaa "Add ability to change linker warning messages into
errors when reporting executable stacks and/or executable segments."
Introduced two new help strings for --enable-error-execstack and
--enable-error-rwx-segments in configure.ac which weren't included
in ld/configure when regenerated.
* gas/config.in: Regenerate.
* ld/configure: Likewise.
The tests are not compatible with ilp32 abi: the GNU property
note is ABI dependent (size changes) and the disasm is ABI
dependent too. Making the test portable between the ABIs is
not trivial.
For now force lp64 abi.
In a safety context, it could interesting to track the trampolines being
generated, ensuring there are expected or not.
bfd/ChangeLog:
* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.
ld/ChangeLog:
* ld.texi (--print-map): Add new item about fixups.
PR ld/30722
Tests looking for certain .note-section recorded properties may not
involve object files from the underlying platform (e.g. via using the C
compiler for linking): Such object files may themselves have similar
note sections, and hence they may influence the overall outcome.
For now convert just the tests known to be affected by crt*.o coming
with "ISA v3 needed" notes. Eventually other tests ought to be
converted, too.
This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1.
It wrongly altered testcase expectations; the issue will need
taking care of differently.
