Tamar Christina [Fri, 19 Oct 2018 15:18:37 +0000 (16:18 +0100)]
Arm: Skip new binary decode tests on pe targets
The two new test I added require the use of the ".inst" directive which the PE
targets don't support. Because of that I excluded *-unknown-pe but the mask needs
to be wider. I am now excluding *-*-pe.
gas/ChangeLog:
* testsuite/gas/arm/undefined-insn-arm.d: Widen pe skip.
* testsuite/gas/arm/undefined-insn-thumb.d: Likewise.
Tamar Christina [Fri, 19 Oct 2018 09:31:42 +0000 (10:31 +0100)]
Arm: Fix disassembler crashing on -b binary when thumb file and thumb not forced.
The disassembler for Arm has some aborts in it in places it assumes can never
be reached. Under normal circumstances they indeed cannot be reached because
the right options are selected from the ARM attributes in the ELF file.
However when disassembling with -b binary then if you do not get the options
right the disassembler just aborts. This changes it so it just prints how it
was trying to interpret the instruction and prints UNKNOWN instructions next to it.
This way the user has an idea of what's going.
gas/ChangeLog:
* testsuite/gas/arm/undefined-insn-arm.d: New test.
* testsuite/gas/arm/undefined-insn-thumb.d: New test.
* testsuite/gas/arm/undefined-insn.s: New test.
opcodes/ChangeLog:
* arm-dis.c (UNKNOWN_INSTRUCTION_32BIT): Format specifier for arm mode.
(UNKNOWN_INSTRUCTION_16BIT): Format specifier for thumb mode.
(print_insn_arm, print_insn_thumb16, print_insn_thumb32): Use them.
AArch64: Fix error checking for SIMD udot (by element)
Committed on behalf of Matthew Malcomson:
The SIMD UDOT instruction assembly has an unusual operand that selects a single
32 bit element with the mnemonic 4B.
This unusual mnemonic is handled by a special operand qualifier and associated
qualifier data in `aarch64_opnd_qualifiers`.
The current qualifier data describes 4 1-byte elements with the structure
{1, 4, 0x0, "4b", OQK_OPD_VARIANT}
This makes sense, as the instruction does work on 4 1-byte elements, however
some logic in the `operand_general_constraint_met_p` makes assumptions about
the range of index allowed when selecting a SIMD_ELEMENT depending on element
size.
That function reasons that e.g. in order to select a byte-sized element in a 16
byte V register an index must allow selection of one of the 16 elements and
hence its range will be in [0,15].
This reasoning breaks with the above description of a 4 part selection of 1
byte elements and allows an index outside the valid [0,3] range, triggering an
assert later on in the program in `aarch64_ins_reglane`.
This patch changes the operand qualifier data so that it describes a single
32 bit element.
{4, 1, 0x0, "4b", OQK_OPD_VARIANT}
Hence the calculation in `operand_general_constraint_met_p` provides the
correct answer and the usual error checking machinery is used.
vshcmd: > echo 'udot v0.2s, v1.8b, v2.4b[4]' | ../src/binutils-build/gas/as-new -march=armv8.4-a
{standard input}: Assembler messages:
{standard input}:1: Error: register element index out of range 0 to 3 at operand 3 -- `udot v0.2s,v1.8b,v2.4b[4]'
Tamar Christina [Tue, 18 Sep 2018 13:36:37 +0000 (14:36 +0100)]
Fix Aarch64 bug in warning filtering.
This fixes a small bug with the warning filtering code, which when a line has
generated a warning and a template decode error (due to the way templates are
resolved) which would not have been emitted and warnings are being suppressed
with -W it would erroneously emit the error.
I have no testcase for this because the only places we generate warnings during
encoding/decoding now is using msr/mrs and system registers. They don't have a
template that would trigger this.
However an upcoming patch series will have tests in it which would expose this bug.
gas/ChangeLog:
* config/tc-aarch64.c (output_operand_error_report): Apply filtering to
current instead of head message.
H.J. Lu [Sat, 25 Aug 2018 13:17:52 +0000 (06:17 -0700)]
elf: Check for corrupt symbol version info
The BFD linker with PR ld/23499 may generate shared libraries with
corrupt symbol version info which leads to linker error when the
corrupt shared library is used:
/usr/bin/ld: bin/libKF5Service.so.5.49.0: _edata: invalid version 21 (max 0)
/usr/bin/ld: bin/libKF5Service.so.5.49.0: error adding symbols: bad value
Add check for corrupt symbol version info to objdump:
H.J. Lu [Fri, 10 Aug 2018 19:21:58 +0000 (12:21 -0700)]
Always clear h->verinfo.verdef when overriding a dynamic definition
When linker defines a symbol to override a dynamic definition, it should
always clear h->verinfo.verdef so that the symbol won't be associated
with the version information from the dynamic object. This happened to
the symbol "_edata" when creating an unversioned dynamic object linking
against:
libQt5Xml.so.5.11.1
299: 000000000003e000 0 NOTYPE GLOBAL DEFAULT 18 _edata@@Qt_5
libQt5DBus.so.5.11.1
597: 0000000000092018 0 NOTYPE GLOBAL DEFAULT 18 _edata@@Qt_5
libQt5Core.so.5.11.1
2292: 00000000004df640 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
2293: 00000000004df640 0 NOTYPE GLOBAL DEFAULT 21 _edata@Qt_5
The problem is triggered by 2 duplicated entries of _edata@Qt_5 in
libQt5Core.so.5.11.1 which was created by gold. Before this commit,
ld created the dynamic object with "_edata" in its dynamic symbol table
which was linker defined and associated with the version information
from libQt5Core.so.5.11.1. The code in question was there when the
binutils source was imported to sourceware.org. When such a dynamic
object was used later, we got:
/usr/bin/ld: bin/libKF5Service.so.5.49.0: _edata: invalid version 21 (max 0)
/usr/bin/ld: bin/libKF5Service.so.5.49.0: error adding symbols: bad value
Tested with many ELF targets.
PR ld/23499
* elflink.c (bfd_elf_record_link_assignment): Always clear
h->verinfo.verdef when overriding a dynamic definition.
projects / thirdparty / binutils-gdb.git / log
