Tamar Christina [Tue, 25 May 2021 15:04:04 +0000 (16:04 +0100)]
Arm: Fix forward thumb references [PR gas/25235]
When assembling a forward reference the symbol will be unknown and so during
do_t_adr we cannot set the thumb bit. The bit it set so early to prevent
relaxations that are invalid. i.e. relaxing a Thumb2 to Thumb1 insn when the
symbol is Thumb.
But because it's done so early we miss the case for forward references.
This patch changes it so that we additionally check the thumb bit during the
internal relocation processing.
In principle we should be able to only set the bit during reloc processing but
that would require changes to the other relocations that the instruction could
be relaxed to.
This approach still allows early relaxations (which means that we have less
iteration of internal reloc processing) while still fixing the forward reference
case.
gas/ChangeLog:
2021-05-24 Tamar Christina <tamar.christina@arm.com>
PR gas/25235
* config/tc-arm.c (md_convert_frag): Set LSB when Thumb symbol.
(relax_adr): Thumb symbols 4 bytes.
* testsuite/gas/arm/pr25235.d: New test.
* testsuite/gas/arm/pr25235.s: New test.
Alex Coplan [Wed, 19 May 2021 09:38:23 +0000 (10:38 +0100)]
arm: Fix bugs with MVE vmov from two GPRs to vector lanes
The initial problem I wanted to fix here is that GAS was rejecting MVE
instructions such as:
vmov q3[2], q3[0], r2, r2
with:
Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2'
which is incorrect; such instructions are valid. Note that for moves in
the other direction, e.g.:
vmov r2, r2, q3[2], q3[0]
GAS is correct in rejecting this as it does not make sense to move both
lanes into the same register (the Arm ARM says this is CONSTRAINED
UNPREDICTABLE).
After fixing this issue, I added assembly/disassembly tests for these
vmovs. This revealed several disassembly issues, including incorrectly
marking the moves into vector lanes as UNPREDICTABLE, and disassembling
many of the vmovs as vector loads. These are now fixed.
Regtested on arm-eabi, no regressions.
OK for trunk? What about backports?
Thanks,
Alex
gas/ChangeLog:
* config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving
into the same GPR twice.
* testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message.
* testsuite/gas/arm/mve-vmov-3.d: New test.
* testsuite/gas/arm/mve-vmov-3.s: New test.
opcodes/ChangeLog:
* arm-dis.c (mve_opcodes): Fix disassembly of
MVE_VMOV2_GP_TO_VEC_LANE when idx == 1.
(is_mve_encoding_conflict): MVE vector loads should not match
when P = W = 0.
(is_mve_unpredictable): It's not unpredictable to use the same
source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).
Alan Modra [Wed, 14 Apr 2021 16:03:13 +0000 (01:33 +0930)]
Make objcopy -p work when an output file is specified
More fallout from the PR27456 fixes.
PR 27456
* rename.c (smart_rename): When TO and FROM are equal, just set
file timestamp.
* objcopy.c (strip_main, copy_main): Always call smart_rename.
AArch64: Fix Diagnostic messaging for LD/ST Exclusive.
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.
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.
Tamar Christina [Thu, 1 Apr 2021 16:10:38 +0000 (17:10 +0100)]
PE/Windows x86_64: Fix weak undef symbols after image base change
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
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>
Nick Alcock [Thu, 18 Mar 2021 12:37:52 +0000 (12:37 +0000)]
Add install dependencies for ld -> bfd and libctf -> bfd
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.