PR 27823
* config/tc-z80.c (emit_ld_r_m): Report an illegal load
instruction.
* testsuite/gas/z80/ill_ops.s: New test source file.
* testsuite/gas/z80/ill_ops.d: New test driver.
* testsuite/gas/z80/ill_ops.l: New test error output.
Use the pattern from other projects where we generate the html pages
in a dir named the same as the project. So now we have:
gas/doc/gas.html - single html page
gas/doc/gas/ - multiple html pages
This works for projects that have a doc/ subdir already, but gprof &
ld require a little tweaking since they generate their docs in their
respective toplevels.
This better matches other GNU projects like autoconf/automake where
the html manual is the single page form. We'll support the multi-page
form in a follow up change.
x86-64 uses rela relocations. The comment next to the field's declaration
says "Non-zero values for ELF USE_RELA targets should be viewed with
suspicion ..." And indeed the fields being non-zero causes section
contents to be accumulated into the final relocated values in addition to
the relocations' addends, which is contrary to the ELF spec.
Surely disp processing should access the disp operand, not an imm one.
This is not an active issue only because imms and disps are, at the
moment, overlapping fields of the same union.
i386_finalize_immediate() is used for both AT&T and Intel immediate
operand handling. Move an AT&T-only check to i386_immediate(), which at
the same time allows it to cover other cases as well, giving an overall
better / more consistent diagnostic.
- Drop a pointless & where just before it was checked that the
respective bits are clear already anyway.
- Avoid a not really necessary operand_type_set() and a redundant
operand_type_or() / operand_type_and() pair.
The gotha() relocation mnemonic will be outputted by OpenRISC GCC when
using the -mcmodel=large option. This relocation is used along with
got() to generate 32-bit GOT offsets. This increases the previous GOT
offset limit from the previous 16-bit (64K) limit.
This is needed on large binaries where the GOT grows larger than 64k.
bfd/ChangeLog:
PR 21464
* bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation.
* elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise.
(or1k_final_link_relocate, or1k_elf_relocate_section,
or1k_elf_check_relocs): Likewise.
* libbfd.h (bfd_reloc_code_real_names): Likewise.
* reloc.c: Likewise.
cpu/ChangeLog:
PR 21464
* or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic
for gotha() relocation.
include/ChangeLog:
PR 21464
* elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number.
opcodes/ChangeLog:
PR 21464
* or1k-asm.c: Regenerate.
gas/ChangeLog:
PR 21464
* testsuite/gas/or1k/reloc-1.s: Add test for new relocation.
* testsuite/gas/or1k/reloc-1.d: Add test result for new
relocation.
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
fixup reloc, add tests
Now that lex_got() is uniform for all targets using it, permit COFF
targets to also use @secrel32 with, in particular, .long. This is more
natural than the custom .secrel32 directive, and also allows more
flexibility (the "+six" form of the two added test lines doesn't work
with a .secrel32 equivalent, in that it silently produces an unintended
relocation type).
As an extra benefit this also makes sure that data definitions in Intel
syntax mode would get treated like they do for e.g. ELF targets.
I see no reason at all for us to carry two copies of almost identical
code. The differences, apart from the table entries, are benign. And
the #ifdef-ary doesn't really get any worse.
Allow a few more expression forms when the entire expression can be
resolved at assembly time. For this, i386_validate_fix() needs to
arrange for all processing of the relocation to be deferred to
tc_gen_reloc().
So far this (counter-intuitively) produced the size as recorded in the
(section) symbol. Obtain the section's size instead for section symbols.
(I wonder whether STT_SECTION symbols couldn't properly hold the
section's size in their st_size field, which in turn would likely mean
the internal symbol would also have its size properly updated.)
Note that this is not the same as the .sizeof.() pseudo-operator: @size
yields the local file's contribution to a section, while .sizeof.() gets
resolved by the linker to produce the final full section's size.
As to the 3rd each of the expected output lines in the changed testcase:
I can't find justification for zzz to come after yyy despite them being
defined in the opposite order in source. Therefore I think it's better
to permit both possible outcomes.
PR gas/27763
While the comment in output_jump() was basically correct prior to the
introduction of 64-bit mode, both that and the not-JMP-like behavior of
XBEGIN require adjustments: Branches with 32-bit displacement do not
wrap at 4G in 64-bit mode, and XBEGIN with 16-bit operand size doesn't
wrap at 64k. Similarly %rip-relative addressing doesn't wrap at 4G.
The new testcase points out that for PE/COFF object_64bit didn't get
set so far, preventing in particular the check at the end of
md_convert_frag() to take effect.
For Mach-O the new testcase fails (bogusly), in that only the first two
of the expected errors get raised. Since for Mach-O many testcases
already fail, and since an x86_64-darwin target can't even be configured
for, I didn't think I need to bother.
Note that there are further issues in this area, in particular for
branches with operand size overrides. Such branches, which truncate
%rip / %eip, can't be correctly expressed with ordinary PC-relative
relocations. It's not really clear what to do with them - perhaps the
best we can do is to carry through all associated relocations, leaving
it to the linker (or even loader) to decide (once the final address
layout is known). Same perhaps goes for relocations associated with
32-bit addressing in 64-bit mode.
Add () to !i.prefix[ADDR_PREFIX] to silence GCC 5:
gas/config/tc-i386.c:4152:31: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
&& !i.prefix[ADDR_PREFIX] != (flag_code == CODE_32BIT))
^
* config/tc-i386.c (optimize_encoding): Add () to silence GCC 5.
Over the years I've seen a number of instances where people used
lea (%reg1), %reg2
or
lea symbol, %reg
despite the same thing being expressable via MOV. Since additionally
LEA often has restrictions towards the ports it can be issued to, while
MOV typically gets dealt with simply by register renaming, transform to
MOV when possible (without growing opcode size and without altering
involved relocation types).
Note that for Mach-O the new 64-bit testcases would fail (for
BFD_RELOC_X86_64_32S not having a representation), and hence get skipped
there.
Constants not known at the time an individual insn gets assembled and
going into a sign-extended field still shouldn't be silently truncated
at the time the respective fixup gets resolved.
The change implementing the .persistent family of sections broke the
existing support for the .persistent.bss section in the compiler:
int a __attribute__ ((section (".persistent.bss")));
t.s: Assembler messages:
t.s:4: Warning: setting incorrect section type for .persistent.bss
The compiler encodes it as @nobits but the assembler expects @progbits.
The assembler is incorrect and should treat the section like the compiler.
bfd/
* elf.c (special_sections_p): Add .persistent.bss.
gas/
* testsuite/gas/elf/section25.d: Run it everywhere.
* testsuite/gas/elf/section26.d: Likewise.
* testsuite/gas/elf/section26.s: Add test for .persistent.bss.
LEA behavior without a 64-bit destination is independent of address size
- in particular LEA with 32-bit addressing and 64-bit destination is the
same as LEA with 64-bit addressing and 32-bit destination. IOW checking
merely i.prefix[ADDR_PREFIX] is insufficient. This also means wrong
relocation types (R_X86_64_32S when R_X86_64_32 is needed) were used so
far in such cases.
Note that in one case in build_modrm_byte() the 64-bit check came too
early altogether, and hence gets dropped in favor of the one included in
the new helper. This is benign to non-64-bit code from all I can tell,
but the failure to clear disp16 could have been a latent problem.
In preparation for extending the conditions here defer this check until
operands have been parsed, as certain further attributes will need to
be known for determinig applicability of this check to be correct to
LEA.
While I can't point out any specific case where things break, it looks
wrong to have the consumer of a flag before its producer. Set .disp32
first, then do the possible conversion to signed 32-bit, and finally
check whether the value fits in a signed long.
Truncating an expression's X_add_number to just "long" can result in
confusing output (e.g. an apparently in-range number claimed to be out
of range). Use the abstraction that bfd provides for this.
Take the opportunity and also insert a missing "of".
This patch adds support to four new system registers (RPAOS, RPALOS, PAALLOS,
PAALL) in conjunction with TLBI instruction. This change is part of RME (Realm
Management Extension).
gas/ChangeLog:
2021-04-19 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
* NEWS: Update news.
* testsuite/gas/aarch64/rme.d: Update test.
* testsuite/gas/aarch64/rme.s: Update test.
opcodes/ChangeLog:
2021-04-19 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
* aarch64-opc.c: Add new registers (RPAOS, RPALOS, PAALLOS, PAALL) support for
TLBI instruction.
This patch adds support to two new system registers (CIPAPA, CIGDPAPA) in
conjunction with DC instruction. This change is part of RME (Realm Management
Extension).
gas/ChangeLog:
2021-04-19 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
* testsuite/gas/aarch64/rme.d: Update test.
* testsuite/gas/aarch64/rme.s: Update test.
opcodes/ChangeLog:
2021-04-19 Przemyslaw Wirkus <przemyslaw.wirkus@arm.com>
* aarch64-opc.c: Add new register (CIPAPA, CIGDPAPA) support for
DC instruction.
Its (documented) behavior is unhelpful in particular in 64-bit build
environments: While printing large 32-bit numbers in decimal already
isn't very meaningful to most people, this even more so goes for yet
larger 64-bit numbers. bfd_sprintf_vma() still tries to limit the number
of digits printed (without depending on a build system property), but
uniformly produces hex output.
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.
