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?