Let's make sure what we allow in the CIE initial instructions and what
select_cie_for_fde compares for a match is always in sync. Also
correct the previous patch that allowed DW_CFA_GNU_window_save to be
part of the CIE initial instructions, which was likely a mistake.
PR 27723
* dw2gencfi.c (initial_cie_insn): New function, extracted from..
(select_cie_for_fde): ..here. Simplify.
Writing to a potentially read-only source directory is not good.
* testsuite/gas/m68hc11/m68hc11.exp (gas_m68hc11_message): Don't
write to $srcdir. Use gas_host_run and read output file rather
than gas_start/gas_finish.
When built on a 32-bit host without --enable-64-bit-bfd, powerpc-linux
and other 32-bit powerpc targeted binutils fail to assemble some
power10 prefixed instructions with 34-bit fields. A typical error
seen when running the testsuite is
.../gas/testsuite/gas/ppc/prefix-pcrel.s:10: Error: bignum invalid
In practice this doesn't matter for addresses: 32-bit programs don't
need or use the top 2 bits of a d34 field when calculating addresses.
However it may matter when loading or adding 64-bit constants with
paddi. A power10 processor in 32-bit mode still has 64-bit wide GPRs.
So this patch enables limited support for O_big PowerPC operands, and
corrects sign extension of 32-bit constants using X_extrabit.
* config/tc-ppc.c (insn_validate): Use uint64_t for operand values.
(md_assemble): Likewise. Handle bignum operands.
(ppc_elf_suffix): Handle O_big. Remove unnecessary input_line_pointer
check.
* expr.c: Delete unnecessary forward declarations.
(generic_bignum_to_int32): Return uint32_t.
(generic_bignum_to_int64): Return uint64_t. Compile always.
(operand): Twiddle X_extrabit for unary '~'. Set X_unsigned and
clear X_extrabit for unary '!'.
* expr.h (generic_bignum_to_int32): Declare.
(generic_bignum_to_int64): Declare.
* testsuite/gas/ppc/prefix-pcrel.s,
* testsuite/gas/ppc/prefix-pcrel.d: Add more instructions.
The original discussion is as follows,
https://github.com/riscv/riscv-isa-manual/issues/637
I never considered the prefixes may have multiple letters, like zxm.
But the ISA spec has been updated for a long time that I haven't noticed.
This patch rewrites the part of architecture parser to support parsing
the multi-letter prefixes. Besides, I also improve the parser to report
errors in details. One of the most obvious improvement is - Do not parse
the prefixed extensions according to the orders in the parse_config.
If we do so, then we used to get "unexpected ISA string at end" errors,
but the message is a little bit hard to know what is happening. I Remove
the confused message, and let riscv_parse_prefixed_ext to report the details.
bfd/
* elfxx-riscv.c (riscv_std_z_ext_strtab): Moved forward.
(riscv_std_s_ext_strtab): Likewise.
(riscv_std_h_ext_strtab): Likewise.
(riscv_std_zxm_ext_strtab): Added for the zxm prefix.
(enum riscv_prefix_ext_class): Moved forward and renamed from
riscv_isa_ext_class. Reorder them according to the parsing order,
since the enum values are used to check the orders in the
riscv_compare_subsets.
(struct riscv_parse_prefix_config): Moved forward and renamed from
riscv_parse_config_t. Also removed the ext_valid_p field, the
related functions are replaced by riscv_valid_prefixed_ext.
(parse_config): Moved forward and updated. The more letters of the
prefix string, the more forward it must be defined. Otherwise, we
will get the wrong mapping when using strncmp in riscv_get_prefix_class.
(riscv_get_prefix_class): Moved forward. Support to parse the
multi-letter prefix, like zxm.
(riscv_known_prefixed_ext): New function, check if the prefixed
extension is supported according to the right riscv_std_*_ext_strtab.
(riscv_valid_prefixed_ext): New function, used to replace the
riscv_ext_*_valid_p functions.
(riscv_init_ext_order): Do not set the values for prefix keywords
since they may have multiple letters for now.
(riscv_compare_subsets): Set the order values of prefix keywords
to negative numbers according to the riscv_prefix_ext_class.
(riscv_parse_std_ext): Call riscv_get_prefix_class to see if we
have parsed the prefixed extensions.
(riscv_parse_prefixed_ext): Updated and removed the parameter config.
Report error when the prefix is unknown.
(riscv_parse_subset): Do not parse the prefixed extensions according
to the orders in the parse_config. Remove the confused message and
let riscv_parse_prefixed_ext to report the details.
* elfxx-riscv.h (enum riscv_isa_ext_class): Moved to elfxx-riscv.c.
(riscv_get_prefix_class): Removed to static.
gas/
* testsuite/gas/riscv/march-fail-order-x-std.d: Renamed from
march-fail-porder-x-std.d.
* testsuite/gas/riscv/march-fail-order-z-std.d: Renamed from
march-fail-porder-z-std.d.
* testsuite/gas/riscv/march-fail-order-x-z.d: Renamed from
march-fail-porder-x-z.d.
* testsuite/gas/riscv/march-fail-order-zx-std.l: Added to replace
march-fail-porder.l.
* testsuite/gas/riscv/march-fail-order-x-z.l: Likewise.
* testsuite/gas/riscv/march-fail-order-x.l: Updated.
* testsuite/gas/riscv/march-fail-order-z.l: Likewise.
* testsuite/gas/riscv/march-fail-single-prefix-h.d: Renamed from
march-fail-single-char-h.d.
* testsuite/gas/riscv/march-fail-single-prefix-s.d: Renamed from
march-fail-single-char-s.d.
* testsuite/gas/riscv/march-fail-single-prefix-x.d: Renamed from
march-fail-single-char-x.d.
* testsuite/gas/riscv/march-fail-single-prefix-z.d: Renamed from
march-fail-single-char-z.d.
* testsuite/gas/riscv/march-fail-single-prefix-zmx.d: Added.
* testsuite/gas/riscv/march-fail-single-prefix.l: Added to replace
march-fail-single-prefix.l.
* testsuite/gas/riscv/march-fail-unknown-zxm.d: Added.
* testsuite/gas/riscv/march-fail-unknown-std.l: Updated.
* testsuite/gas/riscv/march-fail-unknown.l: Likewise.
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.
This adds some annotation to Power10 pcrel instructions, displaying
the target address (ie. pc + D34 field) plus a symbol if there is one
at exactly that target address. pld from the .got or .plt will also
look up the entry and display it, symbolically if there is a dynamic
relocation on the entry.
include/
* dis-asm.h (struct disassemble_info): Add dynrelbuf and dynrelcount.
binutils/
* objdump.c (struct objdump_disasm_info): Delete dynrelbuf and
dynrelcount.
(find_symbol_for_address): Adjust for dynrelbuf and dynrelcount move.
(disassemble_section, disassemble_data): Likewise.
opcodes/
* ppc-dis.c (struct dis_private): Add "special".
(POWERPC_DIALECT): Delete. Replace uses with..
(private_data): ..this. New inline function.
(disassemble_init_powerpc): Init "special" names.
(skip_optional_operands): Add is_pcrel arg, set when detecting R
field of prefix instructions.
(bsearch_reloc, print_got_plt): New functions.
(print_insn_powerpc): For pcrel instructions, print target address
and symbol if known, and decode plt and got loads too.
gas/
* testsuite/gas/ppc/prefix-pcrel.d: Update expected output.
* testsuite/gas/ppc/prefix-reloc.d: Likewise.
* gas/testsuite/gas/ppc/vsx_32byte.d: Likewise.
ld/
* testsuite/ld-powerpc/inlinepcrel-1.d: Update expected output.
* testsuite/ld-powerpc/inlinepcrel-2.d: Likewise.
* testsuite/ld-powerpc/notoc2.d: Likewise.
* testsuite/ld-powerpc/notoc3.d: Likewise.
* testsuite/ld-powerpc/pcrelopt.d: Likewise.
* testsuite/ld-powerpc/startstop.d: Likewise.
* testsuite/ld-powerpc/tlsget.d: Likewise.
* testsuite/ld-powerpc/tlsget2.d: Likewise.
* testsuite/ld-powerpc/tlsld.d: Likewise.
* testsuite/ld-powerpc/weak1.d: Likewise.
* testsuite/ld-powerpc/weak1so.d: Likewise.
Note that this doesn't implement the ISA to the letter regarding
dcbtds (and dcbtstds), which says that the TH field may be zero. That
doesn't make sense because allowing TH=0 would mean you no long have a
dcbtds but rather a dcbtct instruction. I'm interpreting the ISA
wording about allowing TH=0 to mean that the TH field of dcbtds is
optional (in which case the TH value is 0b1000).
opcodes/
PR 27676
* ppc-opc.c (DCBT_EO): Move earlier.
(insert_thct, extract_thct, insert_thds, extract_thds): New functions.
(powerpc_operands): Add THCT and THDS entries.
(powerpc_opcodes): Add dcbtstct, dcbtstds, dcbna, dcbtct, dcbtds.
gas/
* testsuite/gas/ppc/pr27676.d,
* testsuite/gas/ppc/pr27676.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.
* testsuite/gas/ppc/dcbt.d: Update.
* testsuite/gas/ppc/power4_32.d: Update.
PR 27217
* config/tc-aarch64.c (my_get_expression): Rename to
aarch64_get_expression. Add a fifth argument to enable deferring
of expression resolution.
(parse_typed_reg): Update calls to my_get_expression.
(parse_vector_reg_list): Likewise.
(parse_immediate_expression): Likewise.
(parse_big_immediate): Likewise.
(parse_shift): Likewise.
(parse_shifter_operand_imm): Likewise.
(parse_operands): Likewise.
(parse_shifter_operand_reloc): Update calls to my_get_expression
and call aarch64_force_reloc to determine the value of the new
fifth argument.
(parse_address_main): Likewise.
(parse_half): Likewise.
(parse_adrp): Likewise.
(aarch64_force_reloc): New function. Contains code extracted from...
(aarch64_force_relocation): ... here.
* testsuite/gas/aarch64/pr27217.s: New test case.
* testsuite/gas/aarch64/pr27217.d: New test driver.
At the very least this has been causing bogus diagnostics, e.g.
.text
.data
.long .bss - .
.long -.text
.bss
yielding
Error: can't resolve `0' {.bss section} - `.text' {.text section}
instead of
Error: can't resolve `0' {*ABS* section} - `.text' {.text section}
In particular for targets overriding any of TC_FORCE_RELOCATION_* & Co
or for ones setting md_register_arithmetic to true the problems may be
worse.
The former two are unused anyway. And having such constants isn't very
helpful either, when they live in a place where updating the register
table wouldn't even allow noticing the need to adjust these constants.
st(1) ... st(7) will never be looked up in the hash table, so there's no
point inserting the entries. It's also not really necessary to do a 2nd
hash lookup after parsing the register number, nor is there a real
reason for having both st and st(0) entries. Plus we can easily do away
with the need for st to be first in the table.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of rounding being in effect off of the type field
of the structure instead.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of broadcast being in effect off of the type field
of the structure instead.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of masking being in effect off of the register
field of the structure instead.
All callers pass unsigned values (in some cases by virtue of passing
non-negative literal numbers).
This in turn requires struct {Mask,RC,Broadcast}_Operation's "operand"
fields to become unsigned, in turn allowing to reduce the amount of
casting needed (the two new casts that are necessary cast _to_
"unsigned" instead of _from_, as that's the form that'll never case
undefined behavior).
In commit 79dec6b7ba ("x86-64: optimize certain commutative
VEX-encoded insns") I missed the fact that there being subtraction
involved here doesn't matter, as absolute differences get summed up.
Just like is already done for VEX/XOP/EVEX encoded insns, record the
encoding space information in the respective opcode modifier field. Do
this again without changing the source table, but rather by deriving the
values from their existing source representation.
While all of MMX, SSE, and SSE2 are included in "generic64", they can be
individually disabled. There are two MOVQ forms lacking respective
attributes. While the MMX one would get refused anyway (due to MMX
registers not recognized with .nommx), the assembler did happily accept
the SSE2 form. Add respective CPU settings to both, paralleling what the
MOVD counterparts have.
The code was checking wrong bit for sign extension. It caused it
to zero-extend instead of sign-extend the immediate value.
2021-03-25 Abid Qadeer <abidh@codesourcery.com>
opcodes/
* nios2-dis.c (nios2_print_insn_arg): Fix sign extension of
immediate in br.n instruction.
gas/
* testsuite/gas/nios2/brn.s: New.
* testsuite/gas/nios2/brn.d: New.
In match_template() i.tm hasn't been filled yet, so it is necessarily t
which needs checking. This is only a latent issue as no other templates
with the same base_opcode have an extension_opcode of 1.
For VEX-encoded ones, all three involved vector registers have to be
distinct. For EVEX-encoded ones an actual mask register has to be in use
and zeroing-masking cannot be used (violation of either will #UD).
Additionally both involved vector registers have to be distinct for
EVEX-encoded gathers.
For INVLPGB the operand count was wrong (besides %edx there's also %ecx
which is an input to the insn). In this case I see little sense in
retaining the bogus 2-operand template. Plus swapping of the operands
wasn't properly suppressed for Intel syntax.
For PVALIDATE, RMPADJUST, and RMPUPDATE bogus single operand templates
were specified. These get retained, as the address operand is the only
one really needed to expressed non-default address size, but only for
compatibility reasons. Proper multi-operand insn get introduced and the
testcases get adjusted / extended accordingly.
While at it also drop the redundant definition of __amd64__ - we already
have x86_64 defined (or not) to distinguish 64-bit and non-64-bit cases.
This is only a partial fix for PR/gas 27419, in that it limits the bad
behavior of accepting mismatched operands to just x32 mode. The full fix
would be to revert commits 27f134698a and b3a3496f83, and to address
the issue in gcc instead.
In the majority of cases we can easily determine the length from the
encoding, irrespective of whether a prefix is specified there as well.
We further don't even need to record the value in the table entries, as
it's easy enough to determine it (without any guesswork, unless an insn
with major opcode 00 appeared that requires a 2nd opcode byte to be
specified explicitly) when installing the chosen template for further
processing.
Should an encoding appear which
- has a major opcode byte of 66, F3, or F2,
- requires a 2nd opcode byte to be specified explicitly,
- doesn't have a mandatory prefix
we'd need to convert all templates presently encoding a mandatory prefix
this way to the Prefix_0X<nn> model to eliminate the respective guessing
i386-gen does.
Just like is already done for legacy encoded insns, record the mandatory
prefix information in the respective opcode modifier field. Do this
without changing the source table, but rather by deriving the values from
their existing source representation.
This is in preparation of opcode_length going away as a field in the
templates. Identify pseudo prefixes by a base opcode of zero instead:
No real prefix has an opcode of zero. This at the same time allows
dropping a curious special case from i386-gen.
Since most attributes are identical for all pseudo prefixes, take the
opportunity and also template them.
In preparation to use PREFIX_0X<nn> attributes also in VEX/XOP/EVEX
encoding templates, renumber the pseudo-enumerators such that their
values can then also be used directly in the respective prefix bit
fields.
Commit 8b65b8953a ("x86: Remove the prefix byte from non-VEX/EVEX
base_opcode") used the opcodeprefix field for two distinct purposes. In
preparation of having VEX/XOP/EVEX and non-VEX templates become similar
in the representatioon of both encoding space and opcode prefixes, split
the field to have a separate one holding an insn's opcode space.
Commit 8b65b8953a ("x86: Remove the prefix byte from non-VEX/EVEX
base_opcode") dropped the mandatory prefix bytes from legacy encoded
insn templates, but failed to also adjust affected MPX-specific checks
in two places.
For the expressions to remain halfway readable, introduce local
variables to hold current_templates->start.
I don't know really why we should lose a space before a '/'. Possibly
it would make sense if '/' started a comment, but otherwise no.
* app.c (do_scrub_chars): Don't lose spaces before a slash.
