tree ec6c7a53cc7f396a04dfb337f4bf65ced61886b3
parent b19384d3c130858bb31a343ea8fce26be71b5998
author Lynn Boger <laboger@linux.vnet.ibm.com> 1541712436 -0500
committer Lynn Boger <laboger@linux.vnet.ibm.com> 1543877661 +0000

ppc64: fixes for ppc64 objdump

The current output for the Go objdump on ppc64 is not correct
in many cases, generating opcodes that are not acceptable by the
Go assembler, and generating operands in the wrong order.

This adds some changes to generate an objdump for ppc64 code so that
the instructions generated are acceptable by the Go assembler,
and where some of the non-obvious operands have more meaningful names.

This includes the following changes:
- Correct some errors in ppc64map to make it work.
- Make a minor update to ppc64.csv to add the Go opcodes that have been
added to the Go assembler that were not in the table.
- Fix ppc64map to generate correct Go opcodes for ppc64 opcodes that end with '.'
indicating condition codes are set. The previous ppc64map was adding '_' at the end
for this case, but then had to be translated in plan9.go to 'CC' and many were not
being translated. This generates the correct suffix in the first step when
generating tables.go.
- Handle compare instructions correctly, since the names don't quite match
and the CR was not always handled correctly.
- Handle index loads and stores correctly, including VMX and VSX.
- Add mappings for all the names where the Go opcode does not match the ppc64 opcode.
- Handle all CR values, not just CR0 for those instructions that use them.
- Provide more information on BC instructions and generate the correct
branch mnemonic (BEQ, BNE, etc.) where possible.
- Make the output more consistent in spacing.
- Add some more testcases to testdata/decode.txt.
- If the instruction word is all 0s, the Go assembler will output WORD $0,
otherwise unrecognized instructions will be identified with '?'. For GNU,
all 0s will decode to .long 0x0 like the binutils objdump. This can happen
following a call to a panic or throw as a trap, or at the end of a function
for alignment purposes.

Note: the decoder does not handle extended opcodes correctly yet. I will add
that support in the next release and add the corresponding testcases.

We are working on an updated ppc64.csv, but I believe what is
there now covers the opcodes that are supported by the Go assembler.

Change-Id: If7fe1a2205512b476f4fb6b29a21f5459430e50c
Reviewed-on: https://go-review.googlesource.com/c/148574
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>