After commit 2e60790cf7 "Remove the
paramstuff word" there is no caller left of the static find function
in doc/chew.c, so it should be removed.
* doc/chew.c (find): Remove.
PR/32298 sframe: no SFrame stack trace info generated for .plt.got
Add support to generate SFrame stack trace info for .plt.got section.
Enhance the current definition of struct elf_x86_sframe_plt to include
initialized SFrame FDE/FREs applicable for .plt.got section. There are
two variants of .plt.got entries: 16 byte and 8 byte.
8 byte:
ff 25 00 00 00 00 jmpq *name@GOTPCREL(%rip)
66 90 xchg %ax,%ax
16 byte:
f3 0f 1e fa endbr64
ff 25 66 2f 00 00 jmpq *name@GOTPCREL(%rip)
66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
For the testcase, define some application symbols such that their PLT
entry is placed in .plt.got and ensure SFrame information is generated
with and without -z ibtplt.
ChangeLog:
PR/32298
* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
PLT GOT entry size is different for IBT vs non IBT PLTs.
* bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for
SFRAME_PLT_GOT.
(_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT.
(_bfd_x86_elf_write_sframe_plt): Likewise.
(_bfd_x86_elf_late_size_sections): Likewise.
(_bfd_x86_elf_finish_dynamic_sections): Likewise.
* bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members
to keep information about PLT GOT entries.
(struct elf_x86_link_hash_table): Add support for creating
SFrame section for .plt.got.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test.
Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt
The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and
.plt.sec entries. It was observed that SFrame information for .plt.sec
section was incorrect. The erroneous assumption was that SFrame stack
trace information for .plt.sec with lazy binding is the same as SFrame
stack trace information for .plt with lazy binding. This is corrected
now by initializing a new SFrame PLT helper object
elf_x86_64_sframe_ibt_plt for lazy PLT with IBT.
Add a testcase where linking with -z ibtplt generates .plt.sec entries and
ensure correct SFrame information for it.
Committed by Indu Bhagat.
ChangeLog:
PR/32296
* bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New
definition elf_x86_64_sframe_ibt_plt. Use it in
elf_x86_64_sframe_plt.
(elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are
different from lazy PLT.
* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for
SFrame for IBT PLT.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new test.
* ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test.
When _creating_ SFrame information for the linker created .plt.sec, the
code correctly checks for presence of .plt.sec. When _writing_ the
SFrame section for the corresponding .plt.sec, however, the conditionals
were wrongly checking for splt. This was causing an assertion at link
time.
This issue has been known to affect glibc build with SFrame enabled.
No testcase is added just yet. A later commit ensures correct SFrame
stack trace information is created for .plt.got. A test case (where only
.plt and .plt.got are created) is added then.
PR/32297 sframe: bfd assertion with empty main on IBT enabled system
Committed by Indu Bhagat.
ChangeLog:
PR/32297
* bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for
plt_second member not for splt.
writevalue didn't handle 64-bit values, dropping the high 32 bits,
and also wrote any value in the range [0,15] as 0.
* tekhex.c (first_phase): Handle *ABS* symbols.
(writevalue): Rewrite.
originally the reason for pre-sizing was that that's easier
for a multi-threaded use of the hash table. That hasn't materialized
yet, so there's not much sense in using the very very conservative
estimates for pre-sizing. Doing the resize on-demand, whenever we
actually need to add a new entry doesn't change performance.
bfd/
merge.c (sec_merge_hash_insert): Resize as needed from here ...
(record_section): ... not from here. Don't calculate estimates,
return bool instead of three-state, regard all errors as soft
errors.
(_bfd_merge_sections): Adjust.
Local absolute symbols are resolved at assembly stage and the symbol
value is placed in the relocation addend. But non-zero addend will
cause an assertion failure during linking.
Forces emission of relocations to defer resolution of local abs symbols
until link time.
bfd/
* elfnn-loongarch.c (loongarch_elf_relax_section): Determine
absolute symbols in advance to avoid ld crash.
gas/
* config/tc-loongarch.c (loongarch_force_relocation): New
function to force relocation.
* config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros
to force relocation.
(loongarch_force_relocation): Function declaration.
* testsuite/gas/loongarch/localpic.d: New test.
* testsuite/gas/loongarch/localpic.s: New test.
the way the overflow check was written wasn't understood by some
GCC versions and produced false positives for the memset call being
called potentially with object sizes that are larger than half
address-space.
if the input sections are near the max supported size (4G)
we might fail to enlarge the hash table. The error handling
for this case didn't quite work. When this happens we can
gracefully fall back to just not deduplicate this section
(and continue with further mergable sections). We were mixing
that with the case of not being able to even allocate a small
structure (in which case we can as well error out completely),
this disentables both cases.
bfd/
PR ld/32260
* merge.c (sec_merge_maybe_resize): Check overflow in ultimate
target type.
(record_section): Return three-state, use new state when unable
to enlarge hash table.
(_bfd_merge_sections): Remove current section from merging
consideration when hashtable can't be enlarged.
Building shared libraries should not be allowed for PC-relative
relocations against external symbols.
Currently LoongArch has no corresponding checks and silently
generates wrong shared libraries.
However, In the first version of the medium cmodel, pcalau12i+jirl was
used for function calls, in which case PC-relative relocations were
allowed.
This is the assertion that vars->string_ptr < vars->end_string_ptr,
ie. when it fails we've overflowed the string buffer area. Caused by
allocating space for import_name but writing symbol_name, and they can
be different.
* peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change.
Change the mmap support added with commit 9ba56acee5 to always mmap
memory with PROT_READ | PROT_WRITE. Prior to that commit most file
contents were read into a buffer allocated with bfd_alloc or
bfd_malloc and thus the memory was read/write. Even after that commit
any section contents with relocations must be read/write to apply the
relocs. Making them all read/write is not a major change, and it
should not introduce any measurable linker slowdown for contents that
are not modified. More importantly, it removes a BFD behaviour
difference that only triggers when large files are involved.
PR 32266
PR 32109
* libbfd.c (bfd_mmap_local): Remove prot param. Always mmap
with PROT_READ | PROT_WRITE. Adjust all calls.
(_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary.
(_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary.
_bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent.
(_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE
regardless of relocs.
* libbfd-in.h: Update decls to suit. Make non-USE_MMAP variants
static inline functions.
* elflink.c: Update all uses of _bfd_mmap functions.
* elf.c: Likewise.
(bfd_elf_get_str_section): Revert commit 656f8fbaae.
* libbfd.h: Regenerate.
Add relaxation support for call36 that jump to PLT entry.
Add relaxation support for call36 with IFUNC symbol.
Add relaxation support for call36 that jump to undefweak symbol.
For undefweak symbol, it can always be relaxed if it have no PLT entry.
Because we set the address of undefweak symbol without PLT entry to PC
like relocate_section.
While for executables properly aligning sections within the file can be
quite relevant, the same is of pretty little importance for relocatable
object files. Avoid passing "true" into
_bfd_elf_assign_file_position_for_section() when dealing with object
files, but compensate minimally by applying log_file_align in such
cases as a cap to the alignment put in place.
Commit 68bbe11833 results in a lot of follow up work, much of which
likely is still to be done. (And yes, since this is all for corrupted
or fuzzed object files, a whole lot of work doesn't much benefit
anyone. It was a bad idea to put NULL in asymbol->name.) So I'm
changing the approach to instead put a unique empty string for symbols
with a corrupted st_name. An empty string won't require much work to
ensure nm, objcopy, objdump etc. won't crash, since these tools
already must work with unnamed local symbols.
The unique empty string is called bfd_symbol_error_name. This patch
uses that name string for corrupted symbols in the ELF and COFF
backends. Such symbols are displayed by nm and objdump as the
translated string "<corrupt>", which is what the COFF backend used to
put directly into corrupted symbols.
ie. it's the way I should have written the original patch, plus a few
tides and cleanups I retained from the reverted patches.
