Hi folks, during developement of my
assembler I was using NASM/NDISASM for mutual cross check and I discovered a couple of minor bugs.
Nasm-bugs mailist seems to to be frozen since March 2016 and Bugzilla doesn't allow formating, so I dare to post it here.
1 ; Bugs found in NASM version 2.14rc15 compiled on Jul 6 2018
2
3 ; NASM bug #1: Version info is not updated.
4 00000000 02 db __NASM_MAJOR__
5 00000001 0D db __NASM_MINOR__ ; I would expect 0E here in NASM version 2.14.
6 00000002 63 db __NASM_SUBMINOR__
7 00000003 69 db __NASM_PATCHLEVEL__
8
9 ; NASM bug #2:
10 ; NASM assembles POP CS as 0x0F in all modes. This single-byte opcode existed only on the 8086/8088,
11 ; see https://www.pcjs.org/pubs/pc/reference/intel/8086/
12 ; I believe NASM should warn that MOV CS,AX or POP CS is an invalid instruction, at least in 64bit mode.
13 bits 64
14 00000004 8EC8 MOV CS,AX ; Assembled incorrectly as 8EC8 without error.
15 00000006 0F POP CS ; Assembled incorrectly as 0F without error.
16
17 ; NASM bug #3:
18 ; NASM incorrectly encodes INVPCID in 64bit mode with superabundant REX.W prefix.
19 ; I believe that all VMX invalidating instructions are promoted to 64 bits.
20 00000007 660F388006 INVEPT RAX,[RSI] ; Assembled correctly, 660F388006 expected.
21 0000000C 660F388106 INVVPID RAX,[RSI] ; Assembled correctly, 660F388106 expected.
22 00000011 66480F388206 INVPCID RAX,[RSI] ; Assembled incorrectly, 660F388206 expected.
23
24 ; NASM bug #4
25 ; SWAPGS should be marked X64,PRIV in https://github.com/ncoden/NASM/blob/master/insns.dat
; Bugs found in NDISASM version 2.14rc15 compiled on Jul 6 2018
; NDISASM bug #1:
; NDISASM -b16
incorrectly disassembles 16bit ModR/M in some SIMD instructions:
; F30F7E0F in 16bit mode incorrectly disassembles as
movq xmm1,xmm12 instead of
movq xmm1,[bx]; F30F2D0F in 16bit mode incorrectly disassembles as
cvtss2si ecx,xmm12 instead of
cvtss2si ecx,[bx]; NDISASM bug #2:
; NASM correctly assembles obsolete CMPXCHG486 rCX,rDX to 0FA7D1
; but NDISASM in 16bit or 32bit mode
cannot disassemble 0FA7D1 back.
; NDISASM bug #3:
; NASM correctly assembles MOVSS XMM1,XMM7 to F30F10CF
; and NDISASM correctly disassembles F30F10CF to movss xmm1,xmm7
; but it does not recognize its alternative encoding
; and
incorrectly disassembles F30F11F9 as
rep xmovups xmm1,xmm7 instead of
movss xmm1,xmm7; NDISASM bug #4:
; NDISASM -b64
incorrectly disassembles 8bit registers R8B..R15B from instruction VPBROADCASTB xmm1,reg
VPBROADCASTQ XMM1,RDX
VPBROADCASTD XMM1,EDX
VPBROADCASTW XMM1,DX
VPBROADCASTB XMM1,DL
VPBROADCASTQ XMM1,R10
VPBROADCASTD XMM1,R10D
VPBROADCASTW XMM1,R10W
VPBROADCASTB XMM1,R10B ; Incorrectly disassembled 62D27D087ACA as
vpbroadcastb xmm1,r10w ; instead of
vpbroadcastb xmm1,r10b; NDISASM bug #5: (seems to be already reported as
3392350)
; NDISASM
incorrectly interprets {sae}, i.e. bit EVEX.b
; For instance VGETEXPPS ZMM1,ZMM2,{sae} is correctly assembled to 62F27D1842CA
; but this is disassembled back as
vgetexpps xmm1,xmm2; NDISASM bug #6:
;
NDISASM ignores bit EVEX.P1.2 (difference between EVEX and MVEX prefix, see
Phi reference.
; I respect the decission to not support Intel Xeon Phi processor,
; but NDISASM should detect that EVEX.P1 bit 2 is 0 (which signalizes MVEX encoding)
; and give up rather than misinterpret the prefix as if it were EVEX.
; For instance 62F178085A4D02 is incorrectly disassembled as
vcvtps2pd xmm1,qword [rbp+0x10] but it should be
vcvtps2pd zmm1,yword [rbp+0x40];
Documentation error at
Chapter 11: Writing 64-bit Code (Unix, Win64)instead of
All known 64-bit platforms except some embedded platforms
require that the stack is 16-byte aligned
at the entry to a function.In order to enforce that, the stack pointer (RSP) needs to be aligned
on an
odd multiple of 8 bytes before the CALL instruction.
should read
All known 64-bit platforms except some embedded platforms
require that the stack is 16-byte aligned
at the CALL OF a function.
In order to enforce that, the stack pointer (RSP) needs to be aligned
on an
even multiple of 8 bytes before the CALL instruction.
I other words, if the first instruction of fastcalled function were
TEST SPL,1000b
it should return NONZERO (ZF=0).
See also
https://blogs.msdn.microsoft.com/oldnewthing/20040114-00/?p=41053/https://agner.org/optimize/calling_conventions.pdf
