SVE defines new names for existing NZCV conditions, to reflect the
result of instructions like PTEST. This patch adds support for these
names.
The patch also adds comments to the disassembly output to show the
alternative names of a condition code. For example:
cinv x0, x1, cc
becomes:
cinv x0, x1, cc // cc = lo, ul, last
and:
b.cc f0 <...>
becomes:
b.cc f0 <...> // b.lo, b.ul, b.last
Doing this for the SVE names follows the practice recommended by the
SVE specification and is definitely useful when reading SVE code.
If the feeling is that it's too distracting elsewhere, we could add
an option to turn it off.
include/
* opcode/aarch64.h (aarch64_cond): Bump array size to 4.
opcodes/
* aarch64-dis.c (remove_dot_suffix): New function, split out from...
(print_mnemonic_name): ...here.
(print_comment): New function.
(print_aarch64_insn): Call it.
* aarch64-opc.c (aarch64_conds): Add SVE names.
(aarch64_print_operand): Print alternative condition names in
a comment.
gas/
* config/tc-aarch64.c (opcode_lookup): Search for the end of
a condition name, rather than assuming that it will have exactly
2 characters.
(parse_operands): Likewise.
* testsuite/gas/aarch64/alias.d: Add new condition-code comments
to the expected output.
* testsuite/gas/aarch64/beq_1.d: Likewise.
* testsuite/gas/aarch64/float-fp16.d: Likewise.
* testsuite/gas/aarch64/int-insns.d: Likewise.
* testsuite/gas/aarch64/no-aliases.d: Likewise.
* testsuite/gas/aarch64/programmer-friendly.d: Likewise.
* testsuite/gas/aarch64/reloc-insn.d: Likewise.
* testsuite/gas/aarch64/b_c_1.d, testsuite/gas/aarch64/b_c_1.s:
New test.
This patch adds new tests for SVE. It also extends diagnostic.[sl] with
checks for some inappropriate uses of MUL and MUL VL in base AArch64
instructions.
gas/testsuite/
* gas/aarch64/diagnostic.s, gas/aarch64/diagnostic.l: Add tests for
invalid uses of MUL VL and MUL in base AArch64 instructions.
* gas/aarch64/sve-add.s, gas/aarch64/sve-add.d, gas/aarch64/sve-dup.s,
gas/aarch64/sve-dup.d, gas/aarch64/sve-invalid.s,
gas/aarch64/sve-invalid.d, gas/aarch64/sve-invalid.l,
gas/aarch64/sve-reg-diagnostic.s, gas/aarch64/sve-reg-diagnostic.d,
gas/aarch64/sve-reg-diagnostic.l, gas/aarch64/sve.s,
gas/aarch64/sve.d: New tests.
gas/
* doc/c-aarch64.texi: Document the "sve" feature.
* config/tc-aarch64.c (REG_TYPE_R_Z_BHSDQ_VZP): New register type.
(get_reg_expected_msg): Handle it.
(aarch64_check_reg_type): Likewise.
(parse_operands): When parsing operands of an SVE instruction,
disallow immediates that match REG_TYPE_R_Z_BHSDQ_VZP.
(aarch64_features): Add an entry for SVE.
The main purpose of the SVE aarch64_insn_classes is to describe how
an index into an aarch64_opnd_qualifier_seq_t is represented in the
instruction encoding. Other instructions usually use flags for this
information, but (a) we're running out of those and (b) the iclass
would otherwise be unused for SVE.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for the new SVE core
and FP register operands.
* aarch64-opc.h (FLD_SVE_Rm, FLD_SVE_Rn, FLD_SVE_Vd, FLD_SVE_Vm)
(FLD_SVE_Vn): New aarch64_field_kinds.
* aarch64-opc.c (fields): Add corresponding entries.
(aarch64_print_operand): Handle the new SVE core and FP register
operands.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm-2.c: Likewise.
* aarch64-dis-2.c: Likewise.
gas/
* config/tc-aarch64.c (parse_operands): Handle the new SVE core
and FP register operands.
[AArch64][SVE 28/32] Add SVE FP immediate operands
This patch adds support for the new SVE floating-point immediate
operands. One operand uses the same 8-bit encoding as base AArch64,
but in a different position. The others use a single bit to select
between two values.
One of the single-bit operands is a choice between 0 and 1, where 0
is not a valid 8-bit encoding. I think the cleanest way of handling
these single-bit immediates is therefore to use the IEEE float encoding
itself as the immediate value and select between the two possible values
when encoding and decoding.
As described in the covering note for the patch that added F_STRICT,
we get better error messages by accepting unsuffixed vector registers
and leaving the qualifier matching code to report an error. This means
that we carry on parsing the other operands, and so can try to parse FP
immediates for invalid instructions like:
fcpy z0, #2.5
In this case there is no suffix to tell us whether the immediate should
be treated as single or double precision. Again, we get better error
messages by picking one (arbitrary) immediate size and reporting an error
for the missing suffix later.
include/opcode/
* aarch64.h (AARCH64_OPND_SVE_FPIMM8): New aarch64_opnd.
(AARCH64_OPND_SVE_I1_HALF_ONE, AARCH64_OPND_SVE_I1_HALF_TWO)
(AARCH64_OPND_SVE_I1_ZERO_ONE): Likewise.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for the new SVE FP
immediate operands.
* aarch64-opc.h (FLD_SVE_i1): New aarch64_field_kind.
* aarch64-opc.c (fields): Add corresponding entry.
(operand_general_constraint_met_p): Handle the new SVE FP immediate
operands.
(aarch64_print_operand): Likewise.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm.h (ins_sve_float_half_one, ins_sve_float_half_two)
(ins_sve_float_zero_one): New inserters.
* aarch64-asm.c (aarch64_ins_sve_float_half_one): New function.
(aarch64_ins_sve_float_half_two): Likewise.
(aarch64_ins_sve_float_zero_one): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_sve_float_half_one, ext_sve_float_half_two)
(ext_sve_float_zero_one): New extractors.
* aarch64-dis.c (aarch64_ext_sve_float_half_one): New function.
(aarch64_ext_sve_float_half_two): Likewise.
(aarch64_ext_sve_float_zero_one): Likewise.
* aarch64-dis-2.c: Regenerate.
gas/
* config/tc-aarch64.c (double_precision_operand_p): New function.
(parse_operands): Use it to calculate the dp_p input to
parse_aarch64_imm_float. Handle the new SVE FP immediate operands.
[AArch64][SVE 27/32] Add SVE integer immediate operands
This patch adds the new SVE integer immediate operands. There are
three kinds:
- simple signed and unsigned ranges, but with new widths and positions.
- 13-bit logical immediates. These have the same form as in base AArch64,
but at a different bit position.
In the case of the "MOV Zn.<T>, #<limm>" alias of DUPM, the logical
immediate <limm> is not allowed to be a valid DUP immediate, since DUP
is preferred over DUPM for constants that both instructions can handle.
- a new 9-bit arithmetic immediate, of the form "<imm8>{, LSL #8}".
In some contexts the operand is signed and in others it's unsigned.
As an extension, we allow shifted immediates to be written as a single
integer, e.g. "#256" is equivalent to "#1, LSL #8". We also use the
shiftless form as the preferred disassembly, except for the special
case of "#0, LSL #8" (a redundant encoding of 0).
[AArch64][SVE 26/32] Add SVE MUL VL addressing modes
This patch adds support for addresses of the form:
[<base>, #<offset>, MUL VL]
This involves adding a new AARCH64_MOD_MUL_VL modifier, which is
why I split it out from the other addressing modes.
For LD2, LD3 and LD4, the offset must be a multiple of the structure
size, so for LD3 the possible values are 0, 3, 6, .... The patch
therefore extends value_aligned_p to handle non-power-of-2 alignments.
include/opcode/
* aarch64.h (AARCH64_OPND_SVE_ADDR_RI_S4xVL): New aarch64_opnd.
(AARCH64_OPND_SVE_ADDR_RI_S4x2xVL, AARCH64_OPND_SVE_ADDR_RI_S4x3xVL)
(AARCH64_OPND_SVE_ADDR_RI_S4x4xVL, AARCH64_OPND_SVE_ADDR_RI_S6xVL)
(AARCH64_OPND_SVE_ADDR_RI_S9xVL): Likewise.
(AARCH64_MOD_MUL_VL): New aarch64_modifier_kind.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for new MUL VL
operands.
* aarch64-opc.c (aarch64_operand_modifiers): Initialize
the AARCH64_MOD_MUL_VL entry.
(value_aligned_p): Cope with non-power-of-two alignments.
(operand_general_constraint_met_p): Handle the new MUL VL addresses.
(print_immediate_offset_address): Likewise.
(aarch64_print_operand): Likewise.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm.h (ins_sve_addr_ri_s4xvl, ins_sve_addr_ri_s6xvl)
(ins_sve_addr_ri_s9xvl): New inserters.
* aarch64-asm.c (aarch64_ins_sve_addr_ri_s4xvl): New function.
(aarch64_ins_sve_addr_ri_s6xvl): Likewise.
(aarch64_ins_sve_addr_ri_s9xvl): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_sve_addr_ri_s4xvl, ext_sve_addr_ri_s6xvl)
(ext_sve_addr_ri_s9xvl): New extractors.
* aarch64-dis.c (aarch64_ext_sve_addr_reg_mul_vl): New function.
(aarch64_ext_sve_addr_ri_s4xvl): Likewise.
(aarch64_ext_sve_addr_ri_s6xvl): Likewise.
(aarch64_ext_sve_addr_ri_s9xvl): Likewise.
* aarch64-dis-2.c: Regenerate.
gas/
* config/tc-aarch64.c (SHIFTED_MUL_VL): New parse_shift_mode.
(parse_shift): Handle it.
(parse_address_main): Handle the new MUL VL addresses.
(parse_operands): Likewise.
[AArch64][SVE 25/32] Add support for SVE addressing modes
This patch adds most of the new SVE addressing modes and associated
operands. A follow-on patch adds MUL VL, since handling it separately
makes the changes easier to read.
The patch also introduces a new "operand-dependent data" field to the
operand flags, based closely on the existing one for opcode flags.
For SVE this new field needs only 2 bits, but it could be widened
in future if necessary.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for the new SVE
address operands.
* aarch64-opc.h (FLD_SVE_imm6, FLD_SVE_msz, FLD_SVE_xs_14)
(FLD_SVE_xs_22): New aarch64_field_kinds.
(OPD_F_OD_MASK, OPD_F_OD_LSB, OPD_F_NO_ZR): New flags.
(get_operand_specific_data): New function.
* aarch64-opc.c (fields): Add entries for FLD_SVE_imm6, FLD_SVE_msz,
FLD_SVE_xs_14 and FLD_SVE_xs_22.
(operand_general_constraint_met_p): Handle the new SVE address
operands.
(sve_reg): New array.
(get_addr_sve_reg_name): New function.
(aarch64_print_operand): Handle the new SVE address operands.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm.h (ins_sve_addr_ri_u6, ins_sve_addr_rr_lsl)
(ins_sve_addr_rz_xtw, ins_sve_addr_zi_u5, ins_sve_addr_zz_lsl)
(ins_sve_addr_zz_sxtw, ins_sve_addr_zz_uxtw): New inserters.
* aarch64-asm.c (aarch64_ins_sve_addr_ri_u6): New function.
(aarch64_ins_sve_addr_rr_lsl): Likewise.
(aarch64_ins_sve_addr_rz_xtw): Likewise.
(aarch64_ins_sve_addr_zi_u5): Likewise.
(aarch64_ins_sve_addr_zz): Likewise.
(aarch64_ins_sve_addr_zz_lsl): Likewise.
(aarch64_ins_sve_addr_zz_sxtw): Likewise.
(aarch64_ins_sve_addr_zz_uxtw): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_sve_addr_ri_u6, ext_sve_addr_rr_lsl)
(ext_sve_addr_rz_xtw, ext_sve_addr_zi_u5, ext_sve_addr_zz_lsl)
(ext_sve_addr_zz_sxtw, ext_sve_addr_zz_uxtw): New extractors.
* aarch64-dis.c (aarch64_ext_sve_add_reg_imm): New function.
(aarch64_ext_sve_addr_ri_u6): Likewise.
(aarch64_ext_sve_addr_rr_lsl): Likewise.
(aarch64_ext_sve_addr_rz_xtw): Likewise.
(aarch64_ext_sve_addr_zi_u5): Likewise.
(aarch64_ext_sve_addr_zz): Likewise.
(aarch64_ext_sve_addr_zz_lsl): Likewise.
(aarch64_ext_sve_addr_zz_sxtw): Likewise.
(aarch64_ext_sve_addr_zz_uxtw): Likewise.
* aarch64-dis-2.c: Regenerate.
gas/
* config/tc-aarch64.c (aarch64_addr_reg_parse): New function,
split out from aarch64_reg_parse_32_64. Handle Z registers too.
(aarch64_reg_parse_32_64): Call it.
(parse_address_main): Add base_qualifier, offset_qualifier
and accept_sve parameters. Handle SVE base and offset registers.
(parse_address): Update call to parse_address_main.
(parse_address_reloc): Likewise.
(parse_sve_address): New function.
(parse_operands): Parse the new SVE address operands.
Some SVE instructions count the number of elements in a given vector
pattern and allow a scale factor of [1, 16] to be applied to the result.
This scale factor is written ", MUL #n", where "MUL" is a new operator.
E.g.:
UQINCD X0, POW2, MUL #2
This patch adds support for this kind of operand.
All existing operators were shifts of some kind, so there was a natural
range of [0, 63] regardless of context. This was then narrowered further
by later checks (e.g. to [0, 31] when used for 32-bit values).
In contrast, MUL doesn't really have a natural context-independent range.
Rather than pick one arbitrarily, it seemed better to make the "shift"
amount a full 64-bit value and leave the range test to the usual
operand-checking code. I've rearranged the fields of aarch64_opnd_info
so that this doesn't increase the size of the structure (although I don't
think its size is critical anyway).
include/opcode/
* aarch64.h (AARCH64_OPND_SVE_PATTERN_SCALED): New aarch64_opnd.
(AARCH64_MOD_MUL): New aarch64_modifier_kind.
(aarch64_opnd_info): Make shifter.amount an int64_t and
rearrange the fields.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add an entry for
AARCH64_OPND_SVE_PATTERN_SCALED.
* aarch64-opc.h (FLD_SVE_imm4): New aarch64_field_kind.
* aarch64-opc.c (fields): Add a corresponding entry.
(set_multiplier_out_of_range_error): New function.
(aarch64_operand_modifiers): Add entry for AARCH64_MOD_MUL.
(operand_general_constraint_met_p): Handle
AARCH64_OPND_SVE_PATTERN_SCALED.
(print_register_offset_address): Use PRIi64 to print the
shift amount.
(aarch64_print_operand): Likewise. Handle
AARCH64_OPND_SVE_PATTERN_SCALED.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm.h (ins_sve_scale): New inserter.
* aarch64-asm.c (aarch64_ins_sve_scale): New function.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_sve_scale): New inserter.
* aarch64-dis.c (aarch64_ext_sve_scale): New function.
* aarch64-dis-2.c: Regenerate.
gas/
* config/tc-aarch64.c (SHIFTED_MUL): New parse_shift_mode.
(parse_shift): Handle it. Reject AARCH64_MOD_MUL for all other
shift modes. Skip range tests for AARCH64_MOD_MUL.
(process_omitted_operand): Handle AARCH64_OPND_SVE_PATTERN_SCALED.
(parse_operands): Likewise.
[AArch64][SVE 23/32] Add SVE pattern and prfop operands
The SVE instructions have two enumerated operands: one to select a
vector pattern and another to select a prefetch operation. The latter
is a cut-down version of the base AArch64 prefetch operation.
Both types of operand can also be specified as raw enum values such as #31.
Reserved values can only be specified this way.
If it hadn't been for the pattern operand, I would have been tempted
to use the existing parsing for prefetch operations and add extra
checks for SVE. However, since the patterns needed new enum parsing
code anyway, it seeemed cleaner to reuse it for the prefetches too.
Because of the small number of enum values, I don't think we'd gain
anything by using hash tables.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for
AARCH64_OPND_SVE_PATTERN and AARCH64_OPND_SVE_PRFOP.
* aarch64-opc.h (FLD_SVE_pattern): New aarch64_field_kind.
(FLD_SVE_prfop): Likewise.
* aarch64-opc.c: Include libiberty.h.
(aarch64_sve_pattern_array): New variable.
(aarch64_sve_prfop_array): Likewise.
(fields): Add entries for FLD_SVE_pattern and FLD_SVE_prfop.
(aarch64_print_operand): Handle AARCH64_OPND_SVE_PATTERN and
AARCH64_OPND_SVE_PRFOP.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.
gas/
* config/tc-aarch64.c (parse_enum_string): New function.
(po_enum_or_fail): New macro.
(parse_operands): Handle AARCH64_OPND_SVE_PATTERN and
AARCH64_OPND_SVE_PRFOP.
[AArch64][SVE 22/32] Add qualifiers for merging and zeroing predication
This patch adds qualifiers to represent /z and /m suffixes on
predicate registers.
include/opcode/
* aarch64.h (AARCH64_OPND_QLF_P_Z): New aarch64_opnd_qualifier.
(AARCH64_OPND_QLF_P_M): Likewise.
opcodes/
* aarch64-opc.c (aarch64_opnd_qualifiers): Add entries for
AARCH64_OPND_QLF_P_[ZM].
(aarch64_print_operand): Print /z and /m where appropriate.
gas/
* config/tc-aarch64.c (vector_el_type): Add NT_zero and NT_merge.
(parse_vector_type_for_operand): Assert that the skipped character
is a '.'.
(parse_predication_for_operand): New function.
(parse_typed_reg): Parse /z and /m suffixes for predicate registers.
(vectype_to_qualifier): Handle NT_zero and NT_merge.
opcodes/
* aarch64-tbl.h (AARCH64_OPERANDS): Add entries for new SVE operands.
* aarch64-opc.h (FLD_SVE_Pd, FLD_SVE_Pg3, FLD_SVE_Pg4_5)
(FLD_SVE_Pg4_10, FLD_SVE_Pg4_16, FLD_SVE_Pm, FLD_SVE_Pn, FLD_SVE_Pt)
(FLD_SVE_Za_5, FLD_SVE_Za_16, FLD_SVE_Zd, FLD_SVE_Zm_5, FLD_SVE_Zm_16)
(FLD_SVE_Zn, FLD_SVE_Zt, FLD_SVE_tzsh): New aarch64_field_kinds.
* aarch64-opc.c (fields): Add corresponding entries here.
(operand_general_constraint_met_p): Check that SVE register lists
have the correct length. Check the ranges of SVE index registers.
Check for cases where p8-p15 are used in 3-bit predicate fields.
(aarch64_print_operand): Handle the new SVE operands.
* aarch64-opc-2.c: Regenerate.
* aarch64-asm.h (ins_sve_index, ins_sve_reglist): New inserters.
* aarch64-asm.c (aarch64_ins_sve_index): New function.
(aarch64_ins_sve_reglist): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_sve_index, ext_sve_reglist): New extractors.
* aarch64-dis.c (aarch64_ext_sve_index): New function.
(aarch64_ext_sve_reglist): Likewise.
* aarch64-dis-2.c: Regenerate.
gas/
* config/tc-aarch64.c (NTA_HASVARWIDTH): New macro.
(AARCH64_REG_TYPES): Add ZN and PN.
(get_reg_expected_msg): Handle them.
(aarch64_check_reg_type): Likewise. Update comment for
REG_TYPE_R_Z_BHSDQ_V.
(parse_vector_type_for_operand): Add a reg_type parameter.
Skip the width for Zn and Pn registers.
(parse_typed_reg): Extend vector handling to Zn and Pn. Update the
call to parse_vector_type_for_operand. Set HASVARTYPE for Zn and Pn,
expecting the width to be 0.
(parse_vector_reg_list): Restrict error about [BHSD]nn operands to
REG_TYPE_VN.
(vectype_to_qualifier): Use S_[BHSD] qualifiers for NTA_HASVARWIDTH.
(parse_operands): Handle the new Zn and Pn operands.
(REGSET16): New macro, split out from...
(REGSET31): ...here.
(reg_names): Add Zn and Pn entries.
[AArch64][SVE 20/32] Add support for tied operands
SVE has some instructions in which the same register appears twice
in the assembly string, once as an input and once as an output.
This patch adds a general mechanism for that.
The patch needs to add new information to the instruction entries.
One option would have been to extend the flags field of the opcode
to 64 bits (since we already rely on 64-bit integers being available
on the host). However, the *_INSN macros mean that it's easy to add
new information as top-level fields without affecting the existing
table entries too much. Going for that option seemed to give slightly
neater code.
include/opcode/
* aarch64.h (aarch64_opcode): Add a tied_operand field.
(AARCH64_OPDE_UNTIED_OPERAND): New aarch64_operand_error_kind.
SVE adds addresses in which the base or offset are vector registers.
The addresses otherwise have the same kind of form as normal AArch64
addresses, including things like SXTW with or without a shift, UXTW
with or without a shift, and LSL.
This patch therefore refactors the address-printing code so that it
can cope with both scalar and vector registers.
opcodes/
* aarch64-opc.c (get_offset_int_reg_name): New function.
(print_immediate_offset_address): Likewise.
(print_register_offset_address): Take the base and offset
registers as parameters.
(aarch64_print_operand): Update caller accordingly. Use
print_immediate_offset_address.
[AArch64][SVE 18/32] Tidy definition of aarch64-opc.c:int_reg
Use a macro to define 31 regular registers followed by a supplied
value for 0b11111. The SVE code will also use this for vector base
and offset registers.
opcodes/
* aarch64-opc.c (BANK): New macro.
(R32, R64): Take a register number as argument
(int_reg): Use BANK.
[AArch64][SVE 16/32] Use specific insert/extract methods for fpimm
FPIMM used the normal "imm" insert/extract methods, with a specific
test for FPIMM in the extract method. SVE needs to use the same
extractors, so rather than add extra checks for specific operand types,
it seemed cleaner to use a separate insert/extract method.
opcodes/
* aarch64-tbl.h (AARCH64_OPERNADS): Use fpimm rather than imm
for FPIMM.
* aarch64-asm.h (ins_fpimm): New inserter.
* aarch64-asm.c (aarch64_ins_fpimm): New function.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis.h (ext_fpimm): New extractor.
* aarch64-dis.c (aarch64_ext_imm): Remove fpimm test.
(aarch64_ext_fpimm): New function.
* aarch64-dis-2.c: Regenerate.
Several of the SVE operands use the aarch64_operand fields array
to store the fields that make up the operand, rather than hard-coding
the names in the C code. This patch adds helpers for inserting and
extracting those fields.
opcodes/
* aarch64-asm.c: Include libiberty.h.
(insert_fields): New function.
(aarch64_ins_imm): Use it.
* aarch64-dis.c (extract_fields): New function.
(aarch64_ext_imm): Use it.
[AArch64][SVE 14/32] Make aarch64_logical_immediate_p take an element size
SVE supports logical immediate operations on 8-bit, 16-bit and 32-bit
elements, treating them as aliases of operations on 64-bit elements in
which the immediate is replicated. This patch therefore replaces the
"32-bit/64-bit" input to aarch64_logical_immediate_p with a more
general "number of bytes" input.
opcodes/
* aarch64-opc.c (aarch64_logical_immediate_p): Replace is32
with an esize parameter.
(operand_general_constraint_met_p): Update accordingly.
Fix misindented code.
* aarch64-asm.c (aarch64_ins_limm): Update call to
aarch64_logical_immediate_p.
1. unsuffixed: "Pn"
2. with a predication type: "Pn/[ZM]"
3. with a size suffix: "Pn.[BHSD]"
No variation is allowed: unsuffixed operands cannot have a (redundant)
suffix, and the suffixes can never be dropped. Unsuffixed Pn are used
in LDR and STR, but they are also used for Pg operands in cases where
the result is scalar and where there is therefore no choice to be made
between "merging" and "zeroing". This means that some Pg operands have
suffixes and others don't.
It would be possible to use context-sensitive parsing to handle
this difference. The tc-aarch64.c code would then raise an error
if the wrong kind of suffix is used for a particular instruction.
However, we get much more user-friendly error messages if we parse
all three forms for all SVE instructions and record the suffix as a
qualifier. The normal qualifier matching code can then report cases
where the wrong kind of suffix is used. This is a slight extension
of existing usage, which really only checks for the wrong choice of
suffix within a particular kind of suffix.
The only catch is a that a "NIL" entry in the qualifier list
specifically means "no suffix should be present" (case 1 above).
NIL isn't a wildcard here. It also means that an instruction that
requires all-NIL qualifiers can fail to match (because a suffix was
supplied when it shouldn't have been); this requires a slight change
to find_best_match.
This patch adds an F_STRICT flag to select this behaviour.
The flag will be set for all SVE instructions. The behaviour
for other instructions doesn't change.
Following on from the previous patch, which converted the
aarch64_reg_parse_32_64 parameters to bfd_booleans, this one
does the same for parse_address_main and parse_address.
It also documents the parameters.
This isn't an attempt to convert the whole file to use bfd_booleans
more often. It's simply trying to avoid inconsistencies with new
SVE parameters.
gas/
* config/tc-aarch64.c (parse_address_main): Turn reloc and
accept_reg_post_index into bfd_booleans. Add commentary.
(parse_address_reloc): Update accordingly. Add commentary.
(parse_address): Likewise. Also change accept_reg_post_index
into a bfd_boolean here.
(parse_operands): Update calls accordingly.
aarch64_reg_parse_32_64 is currently used to parse address registers,
among other things. It returns two bits of information about the
register: whether it's W rather than X, and whether it's a zero register.
SVE adds addressing modes in which the base or offset can be a vector
register instead of a scalar, so a choice between W and X is no longer
enough. It's more convenient to pass the type of register around as
a qualifier instead.
As it happens, two callers of aarch64_reg_parse_32_64 already wanted
the information in the form of a qualifier, so the change feels pretty
natural even without SVE.
Also, the function took two parameters to control whether {W}SP
and (W|X)ZR should be accepted. These parameters were negative
"reject" parameters, but the closely-related parse_address_main
had a positive "accept" parameter (for post-indexed addressing).
One of the SVE patches adds a parameter to parse_address_main
that needs to be passed down alongside the aarch64_reg_parse_32_64
parameters, which as things stood led to an awkward mix of positive
and negative bools. The patch therefore changes the
aarch64_reg_parse_32_64 parameters to "accept_sp" and "accept_rz"
instead.
Finally, the two input parameters and isregzero return value were
all ints but logically bools. The patch changes the types to
bfd_boolean.
gas/
* config/tc-aarch64.c (aarch64_reg_parse_32_64): Return the register
type as a qualifier rather than an "isreg32" boolean. Turn the
SP/ZR control parameters from negative "reject" to positive
"accept". Make them and *ISREGZERO bfd_booleans rather than ints.
(parse_shifter_operand): Update accordingly.
(parse_address_main): Likewise.
(po_int_reg_or_fail): Likewise. Make the same reject->accept
change to the macro parameters.
(parse_operands): Update after the above changes, replacing
the "isreg32" local variable with one called "qualifier".
[AArch64][SVE 10/32] Move range check out of parse_aarch64_imm_float
Since some SVE constants are no longer explicitly tied to the 8-bit
FP immediate format, it seems better to move the range checks out of
parse_aarch64_imm_float and into the callers.
gas/
* config/tc-aarch64.c (parse_aarch64_imm_float): Remove range check.
(parse_operands): Check the range of 8-bit FP immediates here instead.
[AArch64][SVE 09/32] Improve error messages for invalid floats
Previously:
fmov d0, #2
would give an error:
Operand 2 should be an integer register
whereas the user probably just forgot to add the ".0" to make:
fmov d0, #2.0
This patch reports an invalid floating point constant unless the
operand is obviously a register.
The FPIMM8 handling is only relevant for SVE. Without it:
fmov z0, z1
would try to parse z1 as an integer immediate zero (the res2 path),
whereas it's more likely that the user forgot the predicate. This is
tested by the final patch.
gas/
* config/tc-aarch64.c (parse_aarch64_imm_float): Report a specific
low-severity error for registers.
(parse_operands): Report an invalid floating point constant for
if parsing an FPIMM8 fails, and if no better error has been
recorded.
* testsuite/gas/aarch64/diagnostic.s,
testsuite/gas/aarch64/diagnostic.l: Add tests for integer operands
to FMOV.
SVE has single-bit floating-point constants that don't really
have any relation to the AArch64 8-bit floating-point encoding.
(E.g. one of the constants selects between 0 and 1.) The easiest
way of representing them in the aarch64_opnd_info seemed to be
to use the IEEE float representation directly, rather than invent
some new scheme.
This patch paves the way for that by making the code that converts IEEE
doubles to IEEE floats accept any value in the range of an IEEE float,
not just zero and 8-bit floats. It leaves the range checking to the
caller (which already handles it).
gas/
* config/tc-aarch64.c (aarch64_double_precision_fmovable): Rename
to...
(can_convert_double_to_float): ...this. Accept any double-precision
value that converts to single precision without loss of precision.
(parse_aarch64_imm_float): Update accordingly.
[AArch64][SVE 07/32] Replace hard-coded uses of REG_TYPE_R_Z_BHSDQ_V
To remove parsing ambiguities and to avoid register names being
accidentally added to the symbol table, the immediate parsing
routines reject things like:
.equ x0, 0
add v0.4s, v0.4s, x0
An explicit '#' must be used instead:
.equ x0, 0
add v0.4s, v0.4s, #x0
Of course, it wasn't possible to predict what other register
names might be added in future, so this behaviour was restricted
to the register names that were defined at the time. For backwards
compatibility, we should continue to allow things like:
.equ p0, 0
add v0.4s, v0.4s, p0
even though p0 is now an SVE register.
However, it seems reasonable to extend the x0 behaviour above to
SVE registers when parsing SVE instructions, especially since none
of the SVE immediate formats are relocatable. Doing so removes the
same parsing ambiguity for SVE instructions as the x0 behaviour removes
for base AArch64 instructions.
As a prerequisite, we then need to be able to tell the parsing routines
which registers to reject. This patch changes the interface to make
that possible, although the set of rejected registers doesn't change
at this stage.
gas/
* config/tc-aarch64.c (parse_immediate_expression): Add a
reg_type parameter.
(parse_constant_immediate): Likewise, and update calls.
(parse_aarch64_imm_float): Likewise.
(parse_big_immediate): Likewise.
(po_imm_nc_or_fail): Update accordingly, passing down a new
imm_reg_type variable.
(po_imm_of_fail): Likewise.
(parse_operands): Likewise.
Rename parse_neon_reg_list to parse_vector_reg_list and take
in the required register type as an argument. Later patches
will reuse the function for SVE registers.
gas/
* config/tc-aarch64.c (parse_neon_reg_list): Rename to...
(parse_vector_reg_list): ...this and take a register type
as input.
(parse_operands): Update accordingly.
[AArch64][SVE 02/32] Avoid hard-coded limit in indented_print
The maximum indentation needed by aarch64-gen.c grows as more
instructions are added to aarch64-tbl.h. Rather than having to
increase the indentation limit to a higher value, it seemed better
to replace it with "%*s".
A false return from parse_neon_operand_type had an overloaded
meaning: either the parsing failed, or there was nothing to parse
(which isn't necessarily an error). The only caller, parse_typed_reg,
would therefore not consume the suffix if it was invalid but instead
(successfully) parse the register without a suffix. It would still
leave inst.parsing_error with an error about the invalid suffix.
It seems wrong for a successful parse to leave an error message,
so this patch makes parse_typed_reg return PARSE_FAIL instead.
The patch doesn't seem to make much difference in practice.
Most possible follow-on errors use set_first_error and so the
error about the suffix tended to win despite the successful parse.
For consistency with the previous two patches, this one
adds a macro for the two ARMv8.2 table entries. Both table
entries need a non-null aarch64_op field.
I haven't added macros for the RAS and STAT_PROFILE entries
since there's only one of each. The series isn't getting
rid of braced entries altogether, so I've only looked at
replacing things that occur more than once.
opcodes/
* aarch64-tbl.h (V8_2_INSN): New macro.
(aarch64_opcode_table): Use it.
[AArch64] Add OP parameter to aarch64-tbl.h macros
Nick recently wrapped most of aarch64-tbl.h entries in macros
like CORE_INSN. These new macros assumed that the aarch64_op
"op" field of aarch64_opcode is 0 and that the new "verifier"
field is NULL.
However, there are a lot of CORE, SIMD and FP insns whose table
entries need a nonzero aarch64_op field, so these entries
continued to use a braced list instead of a macro. This makes
the table entries less consistent and means that there are still
quite a few braced entries that need to be updated when making
further changes to the aarch64_opcode structure.
I think the number of entries that need a nonzero aarch64_op
field is high enough to justify having an explicit aarch64_op
entry for all CORE, SIMD and FP entries. This patch adds
one and updates all existing uses of the macros. A following
patch makes more use of the macros.
I've followed existing practice by using 0 instead of OP_NIL
for empty aarch64_op fields. Empty fields are still the norm
and you need to know what the fields are when reading the table
anyway, so it was hard to justify an additional patch to replace
all 0 op fields with OP_NIL.
Pedro Alves [Mon, 22 Aug 2016 19:05:09 +0000 (20:05 +0100)]
Fix PR gdb/20505 - Make vDSO detection work with core files
Loading a core dump that was either generated on a system running
pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused
set in the environment, solib-svr4.c:svr4_current_sos fails to filter
out the vDSO, resulting in:
(gdb) core-file corefile.core^M
[New LWP 2362]^M
warning: Could not load shared library symbols for linux-vdso.so.1.^M
Do you need "set solib-search-path" or "set sysroot"?^M
Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M
...
The problem is that gdbarch_vsyscall_range does not support core
inferiors at all.
When live debugging, we're finding the vDSO's start address with
auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the
corresponding mapping, by parsing /proc/PID/maps. When debugging a
core dump, we can also determine the starting address from
auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core
mappings out of the host's /proc. But we can instead look for a
corresponding load segment in the core's bfd.
gdb/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* linux-tdep.c (linux_vsyscall_range_raw): For core inferiors,
find the vDSO's start address with AT_SYSINFO_EHDR too, and
determine the vDSO's size by finding the PT_LOAD segment that
matches AT_SYSINFO_EHDR.
gdb/testsuite/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* gdb.base/vdso-warning.exp: Test core dumps too. Use
with_test_prefix. Factor out bits to ...
(test_no_vdso): ... this new procedure.
Alan Modra [Mon, 22 Aug 2016 01:12:26 +0000 (10:42 +0930)]
Error on unsupported PowerPC ifuncs
The pr19784 tests fail on ppc32 due to a gcc bug. The failure should
be noticed when building both libpr19784a.so and libpr19784b.so,
rather than ld building a buggy libpr19784a.so that fails at run time.
This patch fixes that by moving the @local ifunc check out of
check_relocs, where a call destination may not yet be known to be
ifunc. The patch also adds a related error for -mbss-plt code.
* elf32-ppc.c (ppc_elf_check_relocs): Move error for @local ifunc..
(ppc_elf_relocate_section): ..to here. Comment. Error on
detecting -mbss-plt -fPIC local ifuncs too.
(ppc_elf_size_dynamic_sections): Comment on unnecessary glink
branch table entries.
Carl E. Love [Fri, 19 Aug 2016 18:06:38 +0000 (11:06 -0700)]
Fix missing files for ld when test suite not compiled in the source directory
This patch fixes an issues with six test suite expect files that do not
run correctly when the test suite is not built in the source directory. The
issue is these tests are not using the current "standard_testfile" call
but rather using the older set command to initialize the "testfile",
"srcfile" and "binprefix" variables or are missing the set for the
"binprefix" variable.
-----------------------------------------------
gdb/testsuite/ChangeLog
2016-08-19 Carl Love <cel@us.ibm.com>
* gdb.arch/altivec-regs.exp: Use standard_testfile instead of
maintaining separate logic for constructing the output path.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.arch/ppc-dfp.exp: Likewise.
* gdb.arch/ppc-fp.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.arch/altivec-abi.exp: Likewise, plus added local variable
binprefix for generating the additional binary files.
Yao Qi [Fri, 19 Aug 2016 13:49:31 +0000 (14:49 +0100)]
[AArch64] Match instruction "STP with base register" in prologue
Nowadays, we only match pre-indexed STP in prologue. Due to the change
in gcc, https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html, it
may generate "STP with base register" in prologue, which GDB doesn't
handle. That is to say, previously GCC generates prologue like this,
Yao Qi [Thu, 11 Aug 2016 16:04:11 +0000 (17:04 +0100)]
null-terminate string in linespec_location_completer
If I build gdb with -fsanitize=address and run tests, I get error,
malformed linespec error: unexpected colon^M
(gdb) PASS: gdb.linespec/ls-errs.exp: lang=C: break :
break :=================================================================^M
==3266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000051451 at pc 0x2b5797a972a8 bp 0x7fffd8e0f3c0 sp 0x7fffd8e0f398^M
READ of size 2 at 0x602000051451 thread T0
#0 0x2b5797a972a7 in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x322a7)^M
#1 0x7bd004 in compare_filenames_for_search(char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:316^M
#2 0x7bd310 in iterate_over_some_symtabs(char const*, char const*, int (*)(symtab*, void*), void*, compunit_symtab*, compunit_symtab*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:411^M
#3 0x7bd775 in iterate_over_symtabs(char const*, int (*)(symtab*, void*), void*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:481^M
#4 0x7bda15 in lookup_symtab(char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:527^M
#5 0x7d5e2a in make_file_symbol_completion_list_1 /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5635^M
#6 0x7d61e1 in make_file_symbol_completion_list(char const*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5684^M
#7 0x88dc06 in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:288
....
0x602000051451 is located 0 bytes to the right of 1-byte region [0x602000051450,0x602000051451)^M
mallocated by thread T0 here:
#0 0x2b5797ab97ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef)^M
#1 0xbbfb8d in xmalloc /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:43^M
#2 0x88dabd in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:273^M
#3 0x88e5ef in location_completer(cmd_list_element*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:531^M
#4 0x8902e7 in complete_line_internal /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:964^
The code in question is here
file_to_match = (char *) xmalloc (colon - text + 1);
strncpy (file_to_match, text, colon - text + 1);
it is likely that file_to_match is not null-terminated. The patch is
to strncpy 'colon - text' bytes and explicitly set '\0'.
gdb:
2016-08-19 Yao Qi <yao.qi@linaro.org>
* completer.c (linespec_location_completer): Make file_to_match
null-terminated.
This test only collects the PC, and thus expects to only see one
register in the output of -trace-frame-collected. However, while on
the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above),
on x32, GDB exposes 32-bit $eip as well, as a pseudo-register
(register 204 above). Thus, collecting $pc/$rip automatically always
collects $eip as well.
gdb/testsuite/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* gdb.trace/mi-trace-frame-collected.exp
(test_trace_frame_collected): On x32, expect two registers.
Pedro Alves [Fri, 19 Aug 2016 11:07:46 +0000 (12:07 +0100)]
x32: gdb: Fix 'call' insn relocation with qRelocInsn
Running the fast tracepoints tests against x32 gdbserver exposes a
latent bug. E.g.,:
(gdb)
continue
Continuing.
Reading /media/sf_host-pedro/gdb/mygit/build-ubuntu-x32/gdb/testsuite/outputs/gdb.trace/change-loc/change-loc-2.sl from remote target...
Thread 1 "change-loc" received signal SIGSEGV, Segmentation fault.
func4 () at /home/pedro/gdb/src/gdb/testsuite/gdb.trace/change-loc.h:24
24 }
(gdb) FAIL: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2
The test sets a fast tracepoint on a shared library. On x32, shared
libraries end up loaded somewhere in the upper 2GB of the 4GB address
space x32 has access to. When gdbserver needs to copy an instruction
to execute it in the jump pad, it asks gdb to relocate/adjust it, with
the qRelocInsn packet. gdb converts "call" instructions into a "push
$<2GB-4GB addr> + jmp" sequence, however, the "pushq" instruction sign
extends its operand, so later when the called function returns, it
returns to an incorrectly sign-extended address. E.g.,
0xfffffffffabc0000 instead of 0xfabc0000, resulting in the
segmentation fault.
Fix this by converting calls at such addresses to "sub + mov + jmp"
sequences instead.
gdb/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* amd64-tdep.c (amd64_relocate_instruction) <callq>: Handle return
addresses over 0x7fffffff.
Running fast tracepoint tests on x32 exposes a latent bug in the agent
bytecode jitting. There's a code path that forgets to emit the call
opcode... Whoops. Fixes a bunch of gdb.trace/trace-condition.exp
FAILs, like:
(gdb)
continue
Continuing.
Thread 1 "trace-condition" received signal SIGSEGV, Segmentation fault.
0x7ffec016 in ?? ()
(gdb) FAIL: gdb.trace/trace-condition.exp: ftrace: $rip == *set_point: advance through tracing
gdb/gdbserver/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
Pedro Alves [Fri, 19 Aug 2016 11:07:45 +0000 (12:07 +0100)]
x32: Avoid unsigned long when installing fast tracepoint jump pads
We're casting through unsigned long to write a 64-bit immediate
operand of movabs (the comment said movl, but that was incorrect).
The problem is that unsigned long is 32-bit on x32, so we were writing
fewer bytes than necessary.
Fix this by using an 8 byte memcpy like in other similar places in the
function.
gdb/gdbserver/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (amd64_install_fast_tracepoint_jump_pad): Fix
comment. Use memcpy instead of casting through unsigned long.
Pedro Alves [Fri, 19 Aug 2016 11:07:45 +0000 (12:07 +0100)]
x32 Fast tracepoints: Customize jump pad address
MAP_32BIT is ignored on x32, meaning the jump pad can end up somewhere
between 2GB and 4GB, too far away from the executable for 5-byte
relative jumps (JMP rel32). So on x32, try explicitly placing the
jump pad near the middle of the available address space.
gdb/gdbserver/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* linux-amd64-ipa.c (alloc_jump_pad_buffer) [__ILP32__]: Try
allocating around 0x80000000.
Pedro Alves [Fri, 19 Aug 2016 11:07:44 +0000 (12:07 +0100)]
x32 Fast tracepoints: IPA target descriptions
Building GDB for x32 fails building the IPA, with:
.../src/gdb/gdbserver/linux-amd64-ipa.c: In function ‘const target_desc* get_ipa_tdesc(int)’:
.../src/gdb/gdbserver/linux-amd64-ipa.c:182:14: error: ‘tdesc_amd64_avx_linux’ was not declared in this scope
return tdesc_amd64_avx_linux;
^
.../src/gdb/gdbserver/linux-amd64-ipa.c:184:14: error: ‘tdesc_amd64_mpx_linux’ was not declared in this scope
return tdesc_amd64_mpx_linux;
^
.../src/gdb/gdbserver/linux-amd64-ipa.c:186:14: error: ‘tdesc_amd64_avx_mpx_linux’ was not declared in this scope
return tdesc_amd64_avx_mpx_linux;
^
[...]
The problem is that the IPA is trying to use the 64-bit descriptions,
when it should be using the x32 ones.
gdb/gdbserver/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
PR gdb/20415
* Makefile.in (x32-linux-ipa.o, x32-avx-linux-ipa.o)
(x32-avx512-linux-ipa.o): New rules.
* configure.ac (x86_64-*-linux*): New x32 check.
* configure.srv (ipa_x32_linux_regobj): New.
(x86_64-*-linux*): Use $ipa_x32_linux_regobj if building for x32.
* linux-amd64-ipa.c (get_ipa_tdesc) [__ILP32__]: Return x32
descriptions.
(initialize_low_tracepoint) [__ILP32__]: Initialize x32
descriptions.
* configure: Regenerate.
Alan Modra [Fri, 19 Aug 2016 01:36:53 +0000 (11:06 +0930)]
PowerPC64, Don't copy weak symbol dyn_relocs to weakdef.
At the cost of an extra field in the symbol table hash entries, this
simplification to the relocate_section dynamic reloc test should help
maintainability.
* elf64-ppc.c (struct ppc_link_hash_entry): Add weakref.
(ppc64_elf_copy_indirect_symbol): Set weakref. Don't merge
dyn_relocs for weakdefs.
(alias_readonly_dynrelocs): New function.
(ppc64_elf_adjust_dynamic_symbol): Use alias_readonly_dynrelocs.
(ppc64_elf_relocate_section): Simplify condition under which
dyn_relocs are emitted.
Alan Modra [Fri, 19 Aug 2016 01:36:41 +0000 (11:06 +0930)]
PR 20472, PowerPC64 ifunc confusion
This patch fixes quite a lot of confusion in allocate_dynrelocs over
ifuncs. Function descriptors make ELFv1 quite different to ELFv2.
PR 20472
* elf64-ppc.c (ppc64_elf_before_check_relocs): Tweak abiversion test.
(readonly_dynrelocs): Comment fix.
(global_entry_stub): New function.
(ppc64_elf_adjust_dynamic_symbol): Tweak abiversion test. Match
ELFv2 code deciding on dynamic relocs vs. global entry stubs to
that in size_global_entry_stubs, handling ifunc too. Delete dead
weak sym code.
(allocate_dynrelocs): Ensure dyn_relocs field is cleared when no
dyn_relocs are needed. Correct handling of ifunc dyn_relocs.
Tidy ELIMINATE_COPY_RELOCS code, only setting dynindx for
undefweak syms. Expand and correct comments.
(size_global_entry_stubs): Ensure symbol is defined.
(ppc64_elf_relocate_section): Match condition under which
dyn_relocs are emitted to that in allocate_dynrelocs.
Carl E. Love [Thu, 18 Aug 2016 21:36:36 +0000 (14:36 -0700)]
Add ChangeLog updates to my previous two commits
gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add "Carl Love".
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
Carl Love [Thu, 19 May 2016 17:02:41 +0000 (13:02 -0400)]
Fix for powerpc-power.exp gdb regression test for Power 9
The GDB testsuite reports 5 test failures on Power 7 instructions.
Additionally the ppc test is missing the new Power 9 instructions as
well as a large number of older instructions. Additionally, some
instruction names have changed or been deleted. This patch
fixes the test failures and completely updates the test to make it
consistent with the supported Power 9 instructions listed in:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
The patch fixes the record support of Hardware Transactional Memory
instructions on Power. It also solves a large number of unexpected failures
from gdb.reverse testcases sigall-precsave.exp and sigall-reverse.exp that
occur on distros which glibc uses HTM instructions.
Simon Marchi [Wed, 17 Aug 2016 19:53:29 +0000 (15:53 -0400)]
Add remove-inferiors test
I noticed that the remove-inferiors command was not tested, and as I am
doing some changes related to the user selection, I want to make sure I
don't break it. For example, I want to make sure it's not possible to
remove the current inferior.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp: New file.
* gdb.multi/remove-inferiors.c: New file.
Cary Coutant [Wed, 17 Aug 2016 17:53:31 +0000 (10:53 -0700)]
Fix extraneous complaints about missing expected TLS relocation (i386).
Build the test objects with the in-tree assembler. Also fix some cascading
error messages caused by not resetting the skip_call_tls_get_addr_ flag
after printing the error.
Mike Frysinger [Fri, 22 Jan 2016 03:17:59 +0000 (22:17 -0500)]
sim: unify symbol table handling
The common sim tracing code already handles loading and tracking of
symbols from the target program so that it can show symbol info in
trace/disassembly calls. Once we touch up the trace code and add a
few API callbacks, ports don't need to do loading and searching of
symbol tables themselves anymore.
Matthew Wahab [Mon, 15 Aug 2016 12:09:04 +0000 (13:09 +0100)]
[GDB] Fix builds broken by proc-service changes.
GLIBC BZ#20311 introduced a change to install proc_service.h so that gdb
didn't have to use the version it embeds in gdb_proc_service.h. The
embedded version is guarded by HAVE_PROC_SERVICE_H and
gdb_proc_service.h has a number other of includes and definitions, all
of which are uncondional except for an include for gregset.h. This is
only included if HAVE_PROC_SERIVCE_H is not defined.
This causes a build failure when cross compiling gdb with the latest
glibc because type definitions in gregset are used independently of
HAVE_PROC_SERIVCE_H. In particular, they are used in gdb_proc_service.h
when PRFPREGSET_T_BROKEN is set.
The error messages on the failure are
----
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does
not name a type; did you mean ‘elf_fpregset_t’?
typedef gdb_fpregset_t gdb_prfpregset_t;
^~~~~~~~~~~~~~
elf_fpregset_t
binutils-gdb/gdb/proc-service.c:218:15: error: ‘gdb_prfpregset_t’ does
not name a type; did you mean ‘gdb_fpregset_t’?
const gdb_prfpregset_t *fpregset)
^~~~~~~~~~~~~~~~
gdb_fpregset_t
----
This patch moves the include for gregset.h to before the code guarded by
HAVE_PROC_SERIVCE_H, so that it is always included. This is enough to
fix the build.
2016-08-15 Matthew Wahab <matthew.wahab@arm.com>
PR gdb/20457
* gdb_proc_service.h: Add an include of gregset.h
[!HAVE_PROC_SERVICE_H]: Remove the include of gregset.h.
The error is caused by the access to (*inp)[9] if 9 is out of its bounds.
However [1] looks odd to me, because if strncmp returns true (non-zero),
the following check "(*inp)[9] == ','" makes no sense any more. I
suspect it was a typo in the code we meant to "strncmp () == 0". Another
problem in the code above is that if *inp is "operator,", we first
increment *inp by 9, and then increment it by one again, which is wrong
to me. We should only increment *inp by 8 to skip "operator", and go
back to the loop header to decide where we stop.
gdb:
2016-08-15 Yao Qi <yao.qi@linaro.org>
* location.c (explicit_location_lex_one): Compare the return
value of strncmp with zero. Don't check (*inp)[9]. Increment
*inp by 8.
Mike Frysinger [Mon, 8 Aug 2016 05:06:49 +0000 (13:06 +0800)]
sim: bfin: split out common mach/model defines into arch.h [PR sim/20438]
The current machs.h mixes common enums with Blackfin-specific defines.
This causes us troubles with header inclusion order such that we can't
drop the old SIM_CPU typedef (which is duplicated in common code). By
splitting the two up, we can unwind this dependency chain, and drop the
old typedef. It also fixes building with older gcc versions.
Nick Clifton [Fri, 12 Aug 2016 19:36:20 +0000 (20:36 +0100)]
Warn if the sh_info field of a symbol table does not index the first non-local symbol in the section.
* readelf.c (process_symbol_table): Generate a warning if a local
symbol is found at and offste greater than or equal to the sh_info
field of it's section header.
Nick Clifton [Fri, 12 Aug 2016 10:35:32 +0000 (11:35 +0100)]
Undo the previous change to the aarch64 sim - exporting aarch64_step() - and instead make aarch64_run correctly process sim events.
* simulator.c (aarch64_step): Revert pervious delta.
(aarch64_run): Call sim_events_tick after each
instruction is simulated, and if necessary call
sim_events_process.
* simulator.h: Revert previous delta.
Yao Qi [Fri, 12 Aug 2016 10:02:04 +0000 (11:02 +0100)]
Fix warning in gdb.base/signals-state-child.c
I see the following warning when running signals-state-child.exp.
gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args]
fprintf (out, "sigaction={sa_handler=", i);
^
this patch is to remove the argument from fprintf.
gdb/testsuite:
2016-08-12 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.c (main): Remove "i" from fprintf's
argument list.
Alan Modra [Fri, 12 Aug 2016 04:37:40 +0000 (14:07 +0930)]
Add undefined weak function tests
* testsuite/ld-undefined/weak-fundef.s: New.
* testsuite/ld-undefined/weak-undef.t: Don't specify filename.
* testsuite/ld-undefined/weak-undef.exp: Run new tests. Rearrange
much of old code. Use is_elf_format to select targets.
Nick Clifton [Thu, 11 Aug 2016 14:04:40 +0000 (15:04 +0100)]
Export the single step function from the AArch64 simulator.
* interp.c (sim_create_inferior): Allow for being called with a
NULL abfd parameter. If a bfd is provided, initialise the sim
with that start address.
* simulator.c (HALT_NYI): Just print out the numeric value of the
instruction when not tracing.
(aarch64_step): Change from static to global.
* simulator.h: Add a prototype for aarch64_step().
Pedro Alves [Thu, 11 Aug 2016 11:01:22 +0000 (12:01 +0100)]
Fix fallout from gdb/20413's fix (x32: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER)
Fixes, on NIOS GNU/Linux:
In file included from
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../nat/linux-ptrace.c:26:0:
/scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../gregset.h:27:23:
error: unknown type name 'gregset_t'
#define GDB_GREGSET_T gregset_t
^
Fix this by including sys/procfs.h directly. We shouldn't really be
including a gdb-only header in a gdb/nat/ file, anyway. Whoops.
gdb/ChangeLog:
2016-08-11 Pedro Alves <palves@redhat.com>
PR gdb/20413
* nat/linux-ptrace.c: Include <sys/procfs.h> instead of
"gregset.h".
Nick Clifton [Thu, 11 Aug 2016 09:22:41 +0000 (10:22 +0100)]
Avoid testsuite errors about missing compilers.
PR ld/20436
* testsuite/lib/ld-lib.exp (check_gcc_plugin_enabled): When not
testing remotely, check to see if target compiler is installed
before trying to run it.
parse_aarch64_imm_float was accepting -0.0 even though that's not
a valid immediate for any instruction. The FPIMM0 caller rejected
it, but the FPIMM one would silently treat it as -2.0.
This patch rejects -0.0 and adds testcases to illegal.[sd].
Before the patch, the final error emitted for illegal.s was:
Error: cannot do 16-byte relocation
which was matched by:
[^:]*:569: Error: .*
The error was reported against the last line of the file rather than
the instruction that required the reloc. Adding more instructions
meant that the line number also changed.
Reporting against the wrong line isn't good from a QoI perspective
but isn't what I'm trying to fix here. Until it's fixed, I thought
it would be better to adjust the match to be against an end-of-file
comment rather than against whatever the last instruction happens to be.
gas/
* config/tc-aarch64.c (parse_aarch64_imm_float): Reject -0.0.
* testsuite/gas/aarch64/illegal.s, testsuite/gas/aarch64/illegal.l:
Add tests for -0.0. Add an end-of-file comment.
Alan Modra [Thu, 11 Aug 2016 03:00:52 +0000 (12:30 +0930)]
PowerPC64 ELFv1 undefined weak functions
Undefined weak functions, like __gmon_start__, were not being made
dynamic or emitting plt call code. While the behaviour of undefined
weak symbols is not defined in the ELF standard, the intention on
powerpc64 was to make it possible to link without a definition of such
symbols and at run time behave the same as if a definition was found
at link time in a shared library.
* elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Don't exit with
non_got_ref true in any case where we could have generated dynbss
copies but decide not to do so.
projects / thirdparty / binutils-gdb.git / log
