Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/internal/obj/x86: FSAVE assembled as FNSAVE #23386
What version of Go are you using (
I may be wrong (not fuzzing expert), but maybe validation against external assemblers/disassemblers is more appropriate?
I did some of it using XED for AVX2 and above (including AVX512 with most of it's extensions), so only legacy instructions need heavy testing.
Updated x86.csv can be useful as a foundation for tests code generation (it was used for existing amd64enc.s suite and disassembler "map").
In theory, when x86.csv is updated, we need to re-generate disassembler from it and check the assembler by tests based on it (this part is mostly done, but there is a room for improvements).
But anyway, I think fuzzing can still find places where x86 asm crashes..
(By the way, there are still open issues from previous fuzz attack.)
More complete list of instructions that assembled in incorrect way:
Since current uses of all instructions from the left imply FWAIT (WAIT), but in reality they assembled into forms without WAIT, it could be acceptable to forbid "pseudo" WAIT+op forms and add instructions without WAIT, so programmer can use both forms. This way, invalid code will not be assembled anymore. Probably can be fixed automatically with go fix.
The other way is to change FSAVE to proper encoding, but that will change code behavior silently.
We're also missing operand size override for
FSTENVS (%rax) FSTENV (%rax) FSTENVL (%rax) => 0: 66 d9 30 fnstenvs (%rax) 3: d9 30 fnstenv (%rax) 5: d9 30 fnstenv (%rax)
My proposed solution is described above, but I can't make the final decision here.