Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/objdump: x86 disassembler does not recognize PDEPQ #25617

mmcloughlin opened this issue May 29, 2018 · 3 comments

cmd/objdump: x86 disassembler does not recognize PDEPQ #25617

mmcloughlin opened this issue May 29, 2018 · 3 comments


Copy link

@mmcloughlin mmcloughlin commented May 29, 2018

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)?

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 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 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 /Users/michaelmcloughlin/gocode/src/
  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:
 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)
Copy link
Contributor Author

@mmcloughlin mmcloughlin commented May 29, 2018

#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.

Copy link

@quasilyte quasilyte commented May 29, 2018

@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.

Copy link
Contributor Author

@mmcloughlin mmcloughlin commented May 30, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants