A summary of what this patch set fixes:
For instructions
STXR w0,x2,[x0]
STLXR w0,x2,[x0]
The warning we emit currently is misleading:
Warning: unpredictable: identical transfer and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical transfer and status registers --`stxr w0,x2,[x0]'
it ought to be:
Warning: unpredictable: identical base and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxr w0,x2,[x0]'
For instructions:
ldaxp x0,x0,[x0]
ldxp x0,x0,[x0]
The warning we emit is incorrect
Warning: unpredictable: identical transfer and status registers --`ldaxp x0,x0,[x0]'
Warning: unpredictable: identical transfer and status registers --`ldxp x0,x0,[x0]'
it ought to be:
Warning: unpredictable load of register pair -- `ldaxp x0,x0,[x0]'
Warning: unpredictable load of register pair -- `ldxp x0,x0,[x0]'
For instructions
stlxp w0, x2, x2, [x0]
stxp w0, x2, x2, [x0]
We don't emit any warning when it ought to be:
Warning: unpredictable: identical base and status registers --`stlxp w0,x2,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxp w0,x2,x2,[x0]'
gas/ChangeLog:
2021-04-09 Tejas Belagod <tejas.belagod@arm.com>
* config/tc-aarch64.c (warn_unpredictable_ldst): Clean-up diagnostic messages
for LD/ST Exclusive instructions.
* testsuite/gas/aarch64/diagnostic.s: Add a diagnostic test for STLXP.
* testsuite/gas/aarch64/diagnostic.l: Fix-up test after message clean-up.
(cherry picked from commit dd17020328)
Patch 1: Fix diagnostics for exclusive load/stores and reclassify
Armv8.7-A ST/LD64 Atomics.
Following upstream pointing out some inconsistencies in diagnostics,
https://sourceware.org/pipermail/binutils/2021-February/115356.html
attached is a patch set that fixes the issues. I believe a combination
of two patches mainly contributed to these bugs:
https://sourceware.org/pipermail/binutils/2020-November/113961.htmlhttps://sourceware.org/pipermail/binutils/2018-June/103322.html
A summary of what this patch set fixes:
For instructions
STXR w0,x2,[x0]
STLXR w0,x2,[x0]
The warning we emit currently is misleading:
Warning: unpredictable: identical transfer and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical transfer and status registers --`stxr w0,x2,[x0]'
it ought to be:
Warning: unpredictable: identical base and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxr w0,x2,[x0]'
For instructions:
ldaxp x0,x0,[x0]
ldxp x0,x0,[x0]
The warning we emit is incorrect
Warning: unpredictable: identical transfer and status registers --`ldaxp x0,x0,[x0]'
Warning: unpredictable: identical transfer and status registers --`ldxp x0,x0,[x0]'
it ought to be:
Warning: unpredictable load of register pair -- `ldaxp x0,x0,[x0]'
Warning: unpredictable load of register pair -- `ldxp x0,x0,[x0]'
For instructions
stlxp w0, x2, x2, [x0]
stxp w0, x2, x2, [x0]
We don't emit any warning when it ought to be:
Warning: unpredictable: identical base and status registers --`stlxp w0,x2,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxp w0,x2,x2,[x0]'
For instructions:
st64bv x0, x2, [x0]
st64bv x2, x0, [x0]
We incorrectly warn when its not necessary. This is because we classify them
incorrectly as ldstexcl when it should be lse_atomics in the opcode table.
The incorrect classification makes it pick up the warnings from warning on
exclusive load/stores.
Patch 2: Reclassify Armv8.7-A ST/LD64 Atomics.
This patch reclassifies ST64B{V,V0}, LD64B as lse_atomics rather than ldstexcl
according to their encoding class as specified in the architecture. This also
has the fortunate side-effect of spurious unpredictable warnings getting
eliminated.
For eg. For instruction:
st64bv x0, x2, [x0]
We incorrectly warn when its not necessary:
Warning: unpredictable: identical transfer and status registers --`st64bv x0,x2,[x0]'
This is because we classify them incorrectly as ldstexcl when it should be
lse_atomics in the opcode table. The incorrect classification makes it pick
up the warnings from warning on exclusive load/stores. This patch fixes it
by reclassifying it and no warnings are issued for this instruction.
opcodes/ChangeLog:
2021-04-09 Tejas Belagod <tejas.belagod@arm.com>
* aarch64-tbl.h (struct aarch64_opcode aarch64_opcode_table): Reclassify
LD64/ST64 instructions to lse_atomic instead of ldstexcl.
(cherry picked from commit 52efda8266)
The change in PR19011 changed the image load address from being in the lower
32-bit address space to the higher 64-bit address space.
However when you have a weak undef symbol which stays undef at the end of
linking the linker has to resolve this (Windows loader does not support undef
symbols). As such typically these would resolve to 0.
The relocation used for these weak symbols are the normal 32-bit PC_REL call
relocs. So when doing the overflow check LD checks if the distance between the
symbol and the call is within range. However now that the load address is
> 32-bits and the symbol val is 0 this overflow check will always fail.
As such the linker gives a bogus error. This patch makes the linker not emit
the overflow failure but chooses to still let the check be performed (as it's
mid-end code).
One down side of this is that it does break the common convention that the call
be to sym at 0x0. i.e. before you'd get
401015: 74 05 je 40101c
401017: e8 e4 ef bf ff callq 0
and now you get
140001015: 74 05 je 14000101c
140001017: e8 e4 ef ff bf call 100000000
since the call is PC_REL there's no way to get the range large enough to
resolve to 0. As such I have chosen to leave it as the furthest simple range
that we can still represent.
By only ignoring the error we leave the symbol value itself to still be 0
such that the if(<symbol>) checks still work correctly.
bfd/ChangeLog:
2021-04-01 Tamar Christina <tamar.christina@arm.com>
PR ld/26659
* cofflink.c (_bfd_coff_generic_relocate_section): Ignore overflow.
ld/ChangeLog:
2021-04-01 Tamar Christina <tamar.christina@arm.com>
PR ld/26659
* testsuite/ld-pe/pe.exp: Add test.
* testsuite/ld-pe/pr26659-weak-undef-sym.d: New test.
* testsuite/ld-pe/pr26659-weak-undef-sym.s: New test.
(cherry picked from commit 74edb473c9)
This stops problems parallel-installing if a relink of libctf is needed.
Also adds corresponding install-strip dependencies.
ChangeLog
2021-03-18 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27482
* Makefile.def: Add install-bfd dependencies for install-libctf and
install-ld, and install-strip-bfd dependencies for
install-strip-libctf and install-strip-ld; move the install-ld
dependency on install-libctf to join it.
* Makefile.in: Regenerated.
Undefined weak symbols with non-default visibility are seen as local
by SYMBOL_REFERENCES_LOCAL. This stops a got indirect to relative
optimisation for them, so that pies and dlls don't get non-zero values
when loading somewhere other than the address they are linked at
(which always happens). The optimisation could be allowed for pdes,
but I thought it best not to allow it there too.
bfd/
* elf64-ppc.c (ppc64_elf_relocate_section): Don't optimise got
indirect to pc-relative or toc-relative for undefined symbols.
ld/
* testsuite/ld-powerpc/weak1.d,
* testsuite/ld-powerpc/weak1.r,
* testsuite/ld-powerpc/weak1.s,
* testsuite/ld-powerpc/weak1so.d,
* testsuite/ld-powerpc/weak1so.r: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.
(cherry picked from commit f5b9c288a3)
This makes IR objects use the same logic as normal objects with
respect to what sort of ref/def makes an as-needed library needed.
Testing the binding of the definition is just plain wrong. What
matters is the binding of the reference.
PR 27441
* elf-bfd.h (struct elf_link_hash_entry): Add ref_ir_nonweak.
* elflink.c (elf_link_add_object_symbols): Set ref_ir_nonweak and
use when deciding an as-needed library should be loaded instead
of using the binding of the library definition.
(cherry picked from commit bbaddd4bbe)