Re: NASM 0.98.39 vs. NASM 2.03.01 disassembly

"Wolfgang Kern" <nowhere@xxxxxxxx> wrote in message
news:g8i5kd$n6h$1@xxxxxxxxxxxxxxxxxxxxxxxx
Rod Pemberton wrote:
I'm still not sure what the justification for that tenacious belief
is...

Yes Rod,
you have to say what you found in conflict with the manuals...


I already posted the instruction descriptions from four manuals that clearly
demonstrate that LSL and LAR aren't to be encoded or decoded as 16-bit only,
i.e., Ew notation, for the register source operand. That was a.l.a. 8/17/08
2:35 am in this thread. I also posted in the bug report where Intel
explicitly clarifies that LSL and LAR do actually read 32-bits of register
when the source operand is a register even though that same manual says "Gv,
Ew" in the opcode table.


http://sourceforge.net/tracker/index.php?func=detail&atid=106208&aid=2063064
&group_id=6208

but pleese just mention where you found a bug,
or shall we guess it ?

I posted the "bug" in a.l.a. on 8/16/2008 4:50 pm, about 11 posts ago from
me in this thread. The bug was found by comparing Ndisasm (0.98.39) output
with Ndisasm (2.03.01) output using a list of instructions culled from
0.98.39 insns.dat in order to check Willow's assembler. That's where I
found a bug: by visual comparison. Is that what you're asking? That post
shows that the "bug" is a difference between the way the two versions of
Ndisasm disassemble the LAR and LSL instructions. That's the bug I found: a
difference. Is that what you're asking? I checked a few manuals for the
descriptions of those instructions. Ndisasm (2.03.01) decodings didn't
match the instruction descriptions. That's the bug I confirmed: by reading.
Is that what you're asking? Is was clear from the instructions descriptions
that Ndisasm (2.03.01) decodes a source operand register for LAR and LSL
with a fixed 16-bit operand size which is incorrect according to the
instruction descriptions. So, I posted. Then, Frank said it wasn't a
bug...

I also described the "bug" in the NASM report: "Ndisasm is not decoding LAR
and LSL to a register appropriate for the mode". I also added two links to
a change which I believe caused the problem. Is Nasm64developer's statement
of the exact opposite problem unclear too?

I believe I've reviewed almost 75% of the thread now...


Rod Pemberton

.

Relevant Pages

  • [patch] faster vgetcpu using sidt
    ... Nathan Laredo pointed out the sgdt/sidt/sldt instructions are ... vgetcpu generally uses lsl at present, ... faster than lsl on all x86_64 processors i've tested. ... extern struct vxtime_data vxtime; ...
    (Linux-Kernel)
  • Re: Most Interesting Bug Track Down
    ... Wikipedia's article on IEFBR14 makes amusing reading. ... original one-instruction program had a bug, ... Code bloat wasn't invented in Redmond. ... contains two instructions and the mainframe does not have fractional ...
    (comp.lang.c)
  • Re: Most Interesting Bug Track Down
    ... Wikipedia's article on IEFBR14 makes amusing reading. ... original one-instruction program had a bug, ... Code bloat wasn't invented in Redmond. ... contains two instructions and the mainframe does not have fractional ...
    (comp.lang.c)
  • AutoComplete passwords bug in 6.0.2800.1106.xpsp2.030422-1633
    ... A colleague of mine found a bug in IE AutoComplete/password saving feature that cost him lost password. ... Below are step-by-step instructions to reproduce the bug ... Let IE save updated password for user admin ... I wonder if anyone can reproduce the problem, ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: [OT] Re: Most Interesting Bug Track Down
    ... Wikipedia's article on IEFBR14 makes amusing reading. ... original one-instruction program had a bug, ... Code bloat wasn't invented in Redmond. ... contains two instructions and the mainframe does not have fractional ...
    (comp.lang.c)