Linker adds indirect symbols for versioned symbol aliases, which are
created by ".symver foo, foo@FOO", by checking symbol type, value and
section so that references to foo will be replaced by references to
foo@FOO if foo and foo@FOO have the same symbol type, value and section.
But in IR, since all symbols of the same type have the same value and
section, we can't tell if a symbol is an alias of another symbol by
their types, values and sections. We shouldn't add indirect symbols
for versioned symbol aliases in IR.
bfd/
PR ld/30281
* elflink.c (elf_link_add_object_symbols): Don't add indirect
symbols for ".symver foo, foo@FOO" aliases in IR.
ld/
PR ld/30281
* testsuite/ld-plugin/lto.exp: Add PR ld/30281 test.
* testsuite/ld-plugin/pr30281.t: New file.
* testsuite/ld-plugin/pr30281.c: Likewise.
(cherry picked from commit 79cfb928f5)
We noticed that a warning message about the use of scalar fp16
instructions being UNPREDICTABLE when conditionalized in an IT
block referenced the specific A-class architecture revision
ARMv8.2-A.
Many of these instructions are now also part of ARMv8.1-M, so
the warning message had become misleading. Here we just change
the message to not specify an architecture revision at all and
update all testing accordingly. This was done with a simple
find-n-replace within the binutils sources. No tests have
regressed for the arm target.
gas/ChangeLog:
* config/tc-arm.c (do_scalar_fp16_v82_encode): Remove
ARMv8.2-A from the warning message.
(do_neon_movhf): Likewise
* testsuite/gas/arm/armv8-2-fp16-scalar-bad.l: Likewise
* testsuite/gas/arm/mve-vaddsub-it-bad.l: Likewise
* testsuite/gas/arm/mve-vcvtne-it-bad.l: Likewise
* testsuite/gas/arm/mve-vcvtne-it.d: Likewise
Previously we had experienced issues with assembling a "VCVTNE" instruction
in the presence of the MVE architecture extension, because it could be
interpreted both as:
* The base instruction VCVT + NE for IT predication when inside an IT block.
* The MVE instruction VCVTN + E in the Else of a VPT block.
Given a C reproducer of:
```
int test_function(float value)
{
int ret_val = 10;
if (value != 0.0)
{
ret_val = (int) value;
}
return ret_val;
}
```
GCC generates a VCVTNE instruction based on the `truncsisf2_vfp`
pattern, which will look like:
`vcvtne.s32.f32 s-reg, s-reg`
This still triggers an error due to being misidentified as "vcvtn+e"
Similar errors were found with other type combinations and instruction
patterns (these have all been added to the testing of this patch).
This class of errors was previously worked around by:
https://sourceware.org/pipermail/binutils/2020-August/112728.html
which addressed this by looking at the operand types, however,
that isn't adequate to cover all the extra cases that have been
found. Instead, we add some special-casing logic earlier when
the instructions are parsed that is conditional on whether we are
in a VPT block or not, when the instruction is parsed.
gas/ChangeLog:
* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.
* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.
* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.
* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.
* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.
We were failing to add the offsets of the containing struct/union
in this case, leading to all offsets being relative to the unnamed
struct/union itself.
libctf/
PR libctf/30264
* ctf-types.c (ctf_member_info): Add the offset of the unnamed
member of the current struct as necessary.
* testsuite/libctf-lookup/unnamed-field-info*: New test.
If no suitable qsort_r is found in libc, we fall back to an
implementation in ctf-qsort.c. But this implementation routinely calls
the comparison function with two identical arguments. The comparison
function that ensures that the order of output types is stable is not
ready for this, misinterprets it as a type appearing more that once (a
can-never-happen condition) and fails with an assertion failure.
Fixed, audited for further instances of the same failure (none found)
and added a no-qsort test to my regular testsuite run.
libctf/:
PR libctf/30013
* ctf-dedup.c (sort_output_mapping): Inputs are always equal to
themselves.
We can't free "internal" on errors, since bfd_coff_swap_sym_in may
call bfd_alloc. For example, _bfd_XXi_swap_sym_in may even create new
sections, which use bfd_alloc'd memory. If "internal" is freed, all
more recently bfd_alloc'd memory is also freed.
* coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
error.
(cherry picked from commit bcefc6be97)
glibc's ld.so ignores local dynamic symbols. It's been that way
forever. We therefore can't use them on dynamic relocations. Fixing
that problem uncovered another problem in sorting of dynamic relocs,
caused no doubt by copying make_iplt_section (where we don't want
reloc sorting by the generic gold function, we want iplt relocs last)
to make_lplt_section (where we do want sorting).
PR 30217
* powerpc.cc (branch_needs_plt_entry): New function.
(Target_powerpc::plt_off): Use it here..
(Target_powerpc::Scan::global): ..and here to correct PLT16 reloc
handling for forced-local global symbols.
(Output_data_plt_powerpc::add_entry): Rename "stash"
parameter "is_local". Emit relative relocs for globals that
are forced local, and don't set_needs_dynsym_entry.
(Target_powerpc::make_lplt_section): Don't create a separate
reloc section, use rela_dyn.
(Target_powerpc::make_brlt_section): Likewise.
(cherry picked from commit 0961e63157)
