cmd/objdump: x86 disassembler does not recognize PDEPQ

[mmcloughlin]

What version of Go are you using (go version)?

go version go1.10.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes, confirmed on 1.9.2 and 1.10.2. Not tested on master.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/michaelmcloughlin/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/michaelmcloughlin/gocode"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.10.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.10.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p5/84p384bs42v7pbgfx0db9gq80000gn/T/go-build505202882=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Compiled package with assembly code using PDEPQ. Viewed resulting assembly with go tool objdump.

Gist https://gist.github.com/mmcloughlin/b5bf1bcc7f31222ff2bc510f2777cd79 is a minimal example.

What did you expect to see?

Expect go tool objdump to show the PDEPQ instruction.

What did you see instead?

Output from objdump.sh script is as follows. The objdump tool does not recognize PDEPQ, and instead parses it as a sequence of instructions. Note that Apple's LLVM objdump correctly identifies the instruction.

+ go version
go version go1.10.2 darwin/amd64
+ go test -c
+ go tool objdump -s bmi.PDep bmi.test
TEXT github.com/mmcloughlin/bmi.PDep(SB) /Users/michaelmcloughlin/gocode/src/github.com/mmcloughlin/bmi/pdep.s
  pdep.s:7      0x10e7860       4c8b442408      MOVQ 0x8(SP), R8
  pdep.s:8      0x10e7865       4c8b4c2410      MOVQ 0x10(SP), R9
  pdep.s:10     0x10e786a       c442b3f5        CMC
  pdep.s:10     0x10e786e       d04c8954        RORB $0x1, 0x54(CX)(CX*4)
  pdep.s:12     0x10e7872       2418            ANDL $0x18, AL
  pdep.s:13     0x10e7874       c3          RET
  :-1           0x10e7875       cc          INT $0x3
  :-1           0x10e7876       cc          INT $0x3
  :-1           0x10e7877       cc          INT $0x3
  :-1           0x10e7878       cc          INT $0x3
  :-1           0x10e7879       cc          INT $0x3
  :-1           0x10e787a       cc          INT $0x3
  :-1           0x10e787b       cc          INT $0x3
  :-1           0x10e787c       cc          INT $0x3
  :-1           0x10e787d       cc          INT $0x3
  :-1           0x10e787e       cc          INT $0x3
  :-1           0x10e787f       cc          INT $0x3
+ objdump -disassemble-all bmi.test
+ grep -A 4 bmi.PDep:
github.com/mmcloughlin/bmi.PDep:
 10e7860:   4c 8b 44 24 08  movq    8(%rsp), %r8
 10e7865:   4c 8b 4c 24 10  movq    16(%rsp), %r9
 10e786a:   c4 42 b3 f5 d0  pdepq   %r8, %r9, %r10
 10e786f:   4c 89 54 24 18  movq    %r10, 24(%rsp)

[mmcloughlin]

23386 is potentially linked. @Quasilyte suggested in a comment that the disassembler needs to be updated according to the latest x86.csv. From my limited digging into this, it does seem it could just be a matter of some instruction tables getting out of sync.

[quasilyte]

@mmcloughlin, that's my understanding that it's better to re-generate disassembler than to manually fix all issues (there are potentially a lots of them). It's possible to patch it, but decoder does not understand, for example, all recently added AVX-512 instructions, so it's not a matter of dozens, but hundreds of instructions.

The main problem is that updated x86.csv generator is on halt until some format questions are resolved. The encoder tables (for assembler) are generated from XED tables directly right now. It is possible to generate decoder tables from that too, but this would require discussion as well.

[mmcloughlin]

Thank you for the detailed reply. I'd agree that an automated solution to this is preferable.

I'm interested in learning more and helping out, but it seems that contributing in this area is non-trivial?

[egonelbre]

Noting that the objdump still cannot disassemble the input:

TEXT bmi.PDep.abi0(SB) s:/temp/pdepq/pdep.s
  pdep.s:7              0x505400                4c8b442408              MOVQ 0x8(SP), R8
  pdep.s:8              0x505405                4c8b4c2410              MOVQ 0x10(SP), R9
  pdep.s:10             0x50540a                c442b3f5                CMC
  pdep.s:10             0x50540e                d04c8954                RORB $0x1, 0x54(CX)(CX*4)
  pdep.s:12             0x505412                2418                    ANDL $0x18, AL
  pdep.s:13             0x505414                c3                      RET