Commit Graph

104773 Commits

Author SHA1 Message Date
Tejas Belagod
d6af793d41 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.

(cherry picked from commit dd17020328)
2021-04-09 17:07:29 +01:00
Tejas Belagod
c1d97fe545 AArch64: Fix Atomic LD64/ST64 classification.
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.html
https://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)
2021-04-09 17:03:34 +01:00
GDB Administrator
7af075d6e3 Automatic date update in version.in 2021-04-09 00:00:47 +00:00
GDB Administrator
552c9946b1 Automatic date update in version.in 2021-04-08 00:00:46 +00:00
GDB Administrator
385faa8542 Automatic date update in version.in 2021-04-07 00:00:49 +00:00
GDB Administrator
b620291dfe Automatic date update in version.in 2021-04-06 00:00:39 +00:00
GDB Administrator
208b5e0c25 Automatic date update in version.in 2021-04-05 00:00:41 +00:00
GDB Administrator
71f321eed4 Automatic date update in version.in 2021-04-04 00:00:37 +00:00
GDB Administrator
c456b10bda Automatic date update in version.in 2021-04-03 00:00:36 +00:00
GDB Administrator
c794f234cc Automatic date update in version.in 2021-04-02 00:00:43 +00:00
Tamar Christina
0ff9fad8bf 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

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)
2021-04-01 18:04:00 +01:00
GDB Administrator
b2e0942e79 Automatic date update in version.in 2021-04-01 00:00:40 +00:00
GDB Administrator
f865fc5d4b Automatic date update in version.in 2021-03-31 00:00:38 +00:00
GDB Administrator
1ffce760e5 Automatic date update in version.in 2021-03-30 00:00:38 +00:00
GDB Administrator
06aeca0371 Automatic date update in version.in 2021-03-29 00:00:33 +00:00
GDB Administrator
a4c3572eb3 Automatic date update in version.in 2021-03-28 00:00:52 +00:00
GDB Administrator
d254cb9daf Automatic date update in version.in 2021-03-27 00:00:37 +00:00
GDB Administrator
25f2900334 Automatic date update in version.in 2021-03-26 00:00:37 +00:00
GDB Administrator
5a5381554d Automatic date update in version.in 2021-03-25 00:00:33 +00:00
GDB Administrator
53107f3b1f Automatic date update in version.in 2021-03-24 00:00:40 +00:00
GDB Administrator
c03eea8135 Automatic date update in version.in 2021-03-23 00:00:41 +00:00
H.J. Lu
70d985a00d DWARF: Check version >= 3 for DW_FORM_ref_addr
Check version >= 3, instead of version == 3 || version == 4, for
DW_FORM_ref_addr.

bfd/

	PR ld/27587
	* dwarf2.c (read_attribute_value): Check version >= 3 for
	DW_FORM_ref_addr.

ld/

	PR ld/27587
	* testsuite/ld-x86-64/pr27587.err: New file.
	* testsuite/ld-x86-64/pr27587a.obj.bz2: Likewise.
	* testsuite/ld-x86-64/pr27587b.obj.bz2: Likewise.
	* testsuite/ld-x86-64/x86-64.exp: Run PR ld/27587 test.

(cherry picked from commit 51f6e7a9f4)
2021-03-22 06:26:21 -07:00
GDB Administrator
15c7fb1043 Automatic date update in version.in 2021-03-22 00:00:54 +00:00
GDB Administrator
3c9849a6a3 Automatic date update in version.in 2021-03-21 00:00:35 +00:00
GDB Administrator
b5d2d20b6c Automatic date update in version.in 2021-03-20 00:00:29 +00:00
Nick Alcock
26952c7e3c 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.
2021-03-19 13:20:00 +00:00
GDB Administrator
7c3b5a9edc Automatic date update in version.in 2021-03-19 00:00:28 +00:00
GDB Administrator
2d07be637e Automatic date update in version.in 2021-03-18 00:00:52 +00:00
GDB Administrator
d0e8fe5596 Automatic date update in version.in 2021-03-17 00:00:31 +00:00
GDB Administrator
00249e00d7 Automatic date update in version.in 2021-03-16 00:00:53 +00:00
GDB Administrator
8192cf5846 Automatic date update in version.in 2021-03-15 00:00:47 +00:00
GDB Administrator
9ed578ec62 Automatic date update in version.in 2021-03-14 00:00:33 +00:00
GDB Administrator
52e4abd315 Automatic date update in version.in 2021-03-13 00:00:38 +00:00
GDB Administrator
af5ab58730 Automatic date update in version.in 2021-03-12 00:00:48 +00:00
GDB Administrator
e53decb1ec Automatic date update in version.in 2021-03-11 00:00:45 +00:00
GDB Administrator
139fba8138 Automatic date update in version.in 2021-03-10 00:01:15 +00:00
GDB Administrator
fbb9a7e337 Automatic date update in version.in 2021-03-09 00:00:51 +00:00
GDB Administrator
17affd070e Automatic date update in version.in 2021-03-08 00:00:50 +00:00
GDB Administrator
1e98aad26a Automatic date update in version.in 2021-03-07 00:00:55 +00:00
GDB Administrator
13c558caa5 Automatic date update in version.in 2021-03-06 00:00:38 +00:00
GDB Administrator
c60a71cb7b Automatic date update in version.in 2021-03-05 00:00:50 +00:00
GDB Administrator
0fc2da7221 Automatic date update in version.in 2021-03-04 00:00:51 +00:00
GDB Administrator
b95bb98a8c Automatic date update in version.in 2021-03-03 00:00:47 +00:00
Alan Modra
e748f8e407 PowerPC64 undefined weak visibility vs GOT optimisation
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)
2021-03-02 21:58:03 +10:30
GDB Administrator
339bc7c4a2 Automatic date update in version.in 2021-03-02 00:00:54 +00:00
Alan Modra
e3316baf92 PR27441, inconsistency in weak definitions
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)
2021-03-01 14:52:20 +10:30
GDB Administrator
54a12d44be Automatic date update in version.in 2021-03-01 00:01:04 +00:00
GDB Administrator
d9869a51f5 Automatic date update in version.in 2021-02-28 00:00:36 +00:00
GDB Administrator
0c1eff5884 Automatic date update in version.in 2021-02-27 00:00:47 +00:00
Alan Modra
1aad0a424a Re: Use make_tempname file descriptor in smart_rename
PR 27456
	* rename.c (simple_copy): Mark target_stat ATTRIBUTE_UNUSED.

(cherry picked from commit 40b02646ec)
2021-02-26 17:58:30 +10:30