It's not just REX.W which is ignored with opcode 0x90. The same goes for
REX.R and REX.X as well as empty REX. None of these are forms of
"xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they
also shouldn't be disassembled this way.
While there simplify things: A single hook function suffices, thus
making it unnecessary to keep two expressions in sync. And checking
ins->address_mode for mode_64bit also is unnecessary, as "rex" can be
non-zero only in that case anyway.
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gas/ChangeLog:
* config/tc-s390.c (s390_parse_cpu): Add z16 as alternate CPU
name.
* doc/as.texi: Add z16 and arch14 to CPU string list.
* doc/c-s390.texi: Add z16 to CPU string list.
opcodes/ChangeLog:
* s390-mkopc.c (main): Enable z16 as CPU string in the opcode
table.
This commit adds partial support for disassembler styling in the i386
disassembler.
The i386 disassembler collects the instruction arguments into an array
of strings, and then loops over the array printing the arguments out
later on. The problem is that by the time we print the arguments out
it's not obvious what the type of each argument is.
Obviously this can be fixed, but I'd like to not do that as part of
this commit, rather, I'd prefer to keep this commit as small as
possible to get the basic infrastructure in place, then we can improve
on this, to add additional styling, in later commits.
For now then, I think this commit should correctly style mnemonics,
some immediates, and comments. Everything else will be printed as
plain text, which will include most instruction arguments, unless the
argument is printed as a symbol, by calling the print_address_func
callback.
Ignoring colours, there should be no other user visible changes in the
output of the disassembler in either objdump or gdb.
opcodes/ChangeLog:
* disassembler.c (disassemble_init_for_target): Set
created_styled_output for i386 based targets.
* i386-dis.c: Changed throughout to use fprintf_styled_func
instead of fprintf_func.
Update the RISC-V disassembler to supply style information. This
allows objdump to apply syntax highlighting to the disassembler
output (when the appropriate command line flag is used).
Ignoring colours, there should be no other user visible changes in the
output of the disassembler in either objdump or gdb.
opcodes/ChangeLog:
* disassembler.c (disassemble_init_for_target): Set
created_styled_output for riscv.
* riscv-dis.c: Changed throughout to use fprintf_styled_func
instead of fprintf_func.
This commit adds the _option_ of having disassembler output syntax
highlighted in objdump. This option is _off_ by default. The new
command line options are:
--disassembler-color=off # The default.
--disassembler-color=color
--disassembler-color=extended-color
I have implemented two colour modes, using the same option names as we
use of --visualize-jumps, a basic 8-color mode ("color"), and an
extended 8bit color mode ("extended-color").
The syntax highlighting requires that each targets disassembler be
updated; each time the disassembler produces some output we now pass
through an additional parameter indicating what style should be
applied to the text.
As updating all target disassemblers is a large task, the old API is
maintained. And so, a user of the disassembler (i.e. objdump, gdb)
must provide two functions, the current non-styled print function, and
a new, styled print function.
I don't currently have a plan for converting every single target
disassembler, my hope is that interested folk will update the
disassemblers they are interested in. But it is possible some might
never get updated.
In this initial series I intend to convert the RISC-V disassembler
completely, and also do a partial conversion of the x86 disassembler.
Hopefully having the x86 disassembler at least partial converted will
allow more people to try this out easily and provide feedback.
In this commit I have focused on objdump. The changes to GDB at this
point are the bare minimum required to get things compiling, GDB makes
no use of the styling information to provide any colors, that will
come later, if this commit is accepted.
This first commit in the series doesn't convert any target
disassemblers at all (the next two commits will update some targets),
so after this commit, the only color you will see in the disassembler
output, is that produced from objdump itself, e.g. from
objdump_print_addr_with_sym, where we print an address and a symbol
name, these are now printed with styling information, and so will have
colors applied (if the option is on).
Finally, my ability to pick "good" colors is ... well, terrible. I'm
in no way committed to the colors I've picked here, so I encourage
people to suggest new colors, or wait for this commit to land, and
then patch the choice of colors.
I do have an idea about using possibly an environment variable to
allow the objdump colors to be customised, but I haven't done anything
like that in this commit, the color choices are just fixed in the code
for now.
binutils/ChangeLog:
* NEWS: Mention new feature.
* doc/binutils.texi (objdump): Describe --disassembler-color
option.
* objdump.c (disassembler_color): New global.
(disassembler_extended_color): Likewise.
(disassembler_in_comment): Likewise.
(usage): Mention --disassembler-color option.
(long_options): Add --disassembler-color option.
(objdump_print_value): Use fprintf_styled_func instead of
fprintf_func.
(objdump_print_symname): Likewise.
(objdump_print_addr_with_sym): Likewise.
(objdump_color_for_disassembler_style): New function.
(objdump_styled_sprintf): New function.
(fprintf_styled): New function.
(disassemble_jumps): Use disassemble_set_printf, and reset
disassembler_in_comment.
(null_styled_print): New function.
(disassemble_bytes): Use disassemble_set_printf, and reset
disassembler_in_comment.
(disassemble_data): Update init_disassemble_info call.
(main): Handle --disassembler-color option.
include/ChangeLog:
* dis-asm.h (enum disassembler_style): New enum.
(struct disassemble_info): Add fprintf_styled_func field, and
created_styled_output field.
(disassemble_set_printf): Declare.
(init_disassemble_info): Add additional parameter.
(INIT_DISASSEMBLE_INFO): Add additional parameter.
opcodes/ChangeLog:
* dis-init.c (init_disassemble_info): Take extra parameter,
initialize the new fprintf_styled_func and created_styled_output
fields.
* disassembler.c (disassemble_set_printf): New function definition.
FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
to earlier architectures as well. GAS previously made the RNG registers
conditional on having both armv8.5-a and +rng, but only +rng should be
required.
This seems to be the only feature that was handled like this.
opcodes/
* aarch64-opc.c (SR_RNG): Don't require V8_5.
gas/
* testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
test.
While the spec isn't explicit about this, it pointing out the similarity
with the D extension ought to extend to the ignoring of a meaningless
rounding mode: "Note FCVT.D.W[U] always produces an exact result and is
unaffected by rounding mode." Hence the chosen encodings also ought to
match.
Note that to avoid breaking existing code the forms with a 3rd operand
are not removed, which means there continues to be a difference to
FCVT.D.W[U].
My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".
Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).
Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.
NM=my-nm now does a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM=/usr/bin/my-nm now avoids a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM="my-nm -p../wombat" now does a path search and runs e.g.
/usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)
Regenerate all affected configure scripts.
* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.
By slightly relaxing the checking in operand_type_register_match() we
can fold the vector shift insns with an XMM source as well. While
strictly speaking an overlap in just one size (see the code comment) is
not enough (both operands could have multiple sizes with just a single
common one), this is good enough for all templates we have, or which
could sensibly / usefully appear (within the scope of the present
operand matching model).
Tightening this a little would be possible, but would require broadcast
related information to be passed into the function.
Setting this field risks cpu_flags_all_zero() mistakenly returning
"false" when the object passed in was e.g. the result of ANDing together
two objects which had the bit set, or ANDNing together an object with
the field set and one with the field clear.
While there also avoid setting CpuNo64: Like Cpu64 this is driven
differently anyway and hence shouldn't be set anywhere by default.
Note that the moving of the two items in i386-gen.c's cpu_flags[] is
only for documentation purposes (and slight reducing of overhead), as
the fields are sorted anyway upon program start.
There's no need for the arbitrary special "unknown" token: Simply
recognize the leading ~ and process everything else the same, merely
recording whether to set individual fields to 1 or 0.
While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS
override cpu_arch_flags anyway when -march=iamcu is passed, and there's
no reason to have the stray flag set even if no insn actually is keyed
to it.
The checks done by check_cpu_arch_compatible() were halfway sensible
only at the time where only L1OM support was there. The purpose,
however, has always been to prevent bad uses of .arch (turning off the
base CPU "feature" flag) while at the same time permitting extensions to
be enabled / disabled. In order to achieve this (and to prevent
regressions when L1OM and K1OM support are removed)
- set CpuIAMCU in CPU_IAMCU_FLAGS,
- adjust the IAMCU check in the function itself (the other two similarly
broken checks aren't adjusted as they're slated to be removed anyway),
- avoid calling the function for extentions (which would never have the
base "feature" flag set),
- add a new testcase actually exercising ".arch iamcu" (which would also
regress with the planned removal).
There isn't an actual opcodes implementation for the AMDGCN arch (yet),
this is just the bare minimum to get
$ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
$ make all-binutils
working later in this series.
opcodes/ChangeLog:
* configure.ac: Handle bfd_amdgcn_arch.
* configure: Re-generate.
Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
Let's hope this stays dead, but it's here as a patch separate from
those that removed use of powerpc_macros just in case it needs to be
resurrected.
include/
* opcode/ppc.h (struct powerpc_macro): Delete declaration.
(powerpc_macros, powerpc_num_macros): Likewise..
opcodes/
* ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete.
gas/
* config/tc-ppc.c (ppc_macro): Delete function.
(ppc_macro_hash): Delete.
(ppc_setup_opcodes, md_assemble): Delete macro support.
This moves VLE insn out of the macro table. "e_slwi" and "e_srwi"
already exist in vle_opcodes as distinct instructions rather than
encodings of e_rlwinm.
opcodes/
* ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand.
Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi",
"e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi".
(powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too.
gas/
* testsuite/gas/ppc/vle-simple-5.d: Update.
The extended instructions implemented in powerpc_macros aren't used by
the disassembler. That means instructions like "sldi r3,r3,2" appear
in disassembly as "rldicr r3,r3,2,61", which is annoying since many
other extended instructions are shown.
Note that some of the instructions moved out of the macro table to the
opcode table won't appear in disassembly, because they are aliases
rather than a subset of the underlying raw instruction. If enabled,
rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all
occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many
occurrences in the case of clrlsldi if n <= b was added to the extract
functions.)
The patch also fixes a small bug in opcode sanity checking.
include/
* opcode/ppc.h (PPC_OPSHIFT_SH6): Define.
opcodes/
* ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn),
(insert_crdn, extract_crdn, insert_rrdn, extract_rrdn),
(insert_sldn, extract_sldn, insert_srdn, extract_srdn),
(insert_erdb, extract_erdb, insert_csldn, extract_csldb),
(insert_irdb, extract_irdn): New functions.
(ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb):
Define and add associated powerpc_operands entries.
(powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi",
"sldi", "extldi", "clrlsldi", "insrdi" and corresponding record
(ie. dot suffix) forms.
(powerpc_macros): Delete same from here.
gas/
* config/tc-ppc.c (insn_validate): Don't modify value passed
to operand->insert for PPC_OPERAND_PLUS1 when calculating mask.
Handle PPC_OPSHIFT_SH6.
* testsuite/gas/ppc/prefix-reloc.d: Update.
* testsuite/gas/ppc/simpshft.d: Update.
ld/
* testsuite/ld-powerpc/elfv2so.d: Update.
* testsuite/ld-powerpc/notoc.d: Update.
* testsuite/ld-powerpc/notoc3.d: Update.
* testsuite/ld-powerpc/tlsdesc2.d: Update.
* testsuite/ld-powerpc/tlsget.d: Update.
* testsuite/ld-powerpc/tlsget2.d: Update.
* testsuite/ld-powerpc/tlsopt5.d: Update.
* testsuite/ld-powerpc/tlsopt6.d: Update.
Without a -M cpu option given, powerpc objdump defaults currently to
-Mpower10 but -Many is also given. Commit 1ff6a3b8e5 regressed
-Many disassembly of instructions that are encoded differently
depending on cpu, such as mftb which has pre- and post-power4
encodings.
PR 28959
* ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change. Instead
only look at deprecated PPC_OPCODE_RAW bit when -Many.
Correct issues with INSN2_ALIAS annotation for branch instructions:
- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
BEQ/L and BNE/L respectively with the `rs' operand equal to $0,
- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
BEQ and BNE respectively with the `rt' operand equal to $0,
- regular MIPS BAL assembly instruction is an idiom for architecture
levels of up to the MIPSr5 ISA and a machine instruction on its own
from the MIPSr6 ISA up.
Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:
$ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o
bal.o: file format elf32-tradlittlemips
Disassembly of section .text:
00000000 <foo>:
0: 04110000 0x4110000
...
$
Add test cases accordingly.
Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.
2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk>
binutils/
* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-alias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/mips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
2022-03-06 Sagar Patel <sagarmp@cs.unc.edu>
Maciej W. Rozycki <macro@orcam.me.uk>
opcodes/
* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
"bnez" instructions.
Add has_sib to struct instr_info and use SIB info only if ins->has_sib
is true.
PR binutils/28892
* i386-dis.c (instr_info): Add has_sib.
(get_sib): Set has_sib.
(OP_E_memory): Replace havesib with ins->has_sib.
(OP_VEX): Use ins->sib.index only if ins->has_sib is true.
Now that this lives on the stack, let's have it be a little less
wasteful in terms of space. Switch boolean fields to "bool" (also when
this doesn't change their size) and also limit the widths of "rex",
"rex_used", "op_ad", and "op_index". Do a little bit of re-ordering as
well to limit the number of padding holes.
There's no real need for the pseudo-boolean "haveindex" or for separate
32-bit / 64-bit index pointers. Fold them into a single "indexes" and
set that uniformly to AT&T names, compensating by emitting the register
name via oappend_maybe_intel().
On top of prior similar work more opportunities have appeared in the
meantime. Note that this also happens to address the prior lack of
decoding of EVEX.L'L for VMOV{L,H}P{S,D} and VMOV{LH,HL}PS.
For some reason the original AVFX512F insns were not taken as a basis
here, causing unnecessary divergence. While not an active issue, it is
still relevant to note that OP_XMM() has special treatment of e.g.
scalar_mode (marking broadcast as invalid). Such would better be
consistent for all sufficiently similar insns.
