From: Willow on
On Aug 12, 8:59 am, Herbert Kleebauer <k...(a)unibwm.de> wrote:
[snip]
> I think it would be better to use:
>
> not word [es:bx+0x02] 26 f7 57 02
> not word [es:bx+0x0002] 26 f7 97 0002
> not word [es:dword eax+0x02] 67 26 f7 50 02
> not word [es:dword eax+0x00000002] 67 26 f7 90 00000002

I just fixed it, now it prints this:

00000000 not word [es:bx+0x02]
00000004 not word [es:bx+0x0002]
00000009 not word [es:eax+0x02]
0000000e not word [es:eax+0x00000002]

I changed the tab output to two spaces, and made this change:

s->icode->disp = (U4)(S4)(S1)(U1)s->icode->disp;
// bug fix from release 0.04
s->icode->base.ea.disp8 = 1;
// end bug fix

I also made it omit 'word' or 'dword' in the EA if a 16-bit or 32-bit
base or index register is used.

Thanks for finding this bug!

Latest version is here: http://code.google.com/p/vm64dec/downloads/list


Willow
From: Dave -Turner on
> http://ref.x86asm.net/x86reference.xml

XML Parsing Error: undefined entity
Location: http://ref.x86asm.net/x86reference.xml
Line Number 59, Column 15: <note>&add;</note>
--------------^


From: Nathan Baker on
Willow wrote:
>
> Latest version is here: http://code.google.com/p/vm64dec/downloads/list
>

Looks better. I compiled it for Linux. It works, but ends with this error:

abort: cs segment limit exceeded (or internal error)

Nathan.
From: Willow on
On Aug 12, 10:30 pm, Nathan Baker <Nat...(a)nospam.net> wrote:
> Willow wrote:
>
> > Latest version is here:http://code.google.com/p/vm64dec/downloads/list
>
> Looks better. I compiled it for Linux. It works, but ends with this error:
>
> abort: cs segment limit exceeded (or internal error)
>
> Nathan.

It's great that you got it to work on Linux! How exciting!

Here's a fix for that problem of it ending with an abort:

Code was (curdasm1.cpp):

printf("abort: cs segment limit exceeded (or internal error)\n");

Change to:

for(int i = 0; i < bytesleft; ++i)
printf("%08x db 0x%02x\n", (U4)(loadofs + curofs + i), data[curofs +
i]);

The problem was, sometimes end of file is encountered when an
instruction is in the middle of being decoded, e.g. if the image ends
with 0xb0 (mov al,imm8) then it expects an imm8 but if EOF is found
instead, it aborts! Now I fixed it, made it print db's as shown above.

The next release will incorporate this change, but I don't want to
post it just yet because you built it on Linux and I want the next
release to be more Linux friendly! Did you have to make any changes
when you built it on Linux? Do you know how to make a Makefile for
such a complex project? The problem is there's lots of directories and
also there's some automatically generated code... any help on making a
makefile would be appreciated.


Willow
From: NathanCBaker on
On Aug 13, 2:52 am, Willow <wrschlan...(a)gmail.com> wrote:
>
> The next release will incorporate this change, but I don't want to
> post it just yet because you built it on Linux and I want the next
> release to be more Linux friendly! Did you have to make any changes
> when you built it on Linux? Do you know how to make a Makefile for
> such a complex project? The problem is there's lots of directories and
> also there's some automatically generated code... any help on making a
> makefile would be appreciated.
>

The only thing I did was write two small bash scripts (one for each
subdirectory). But here is a quickly-cobbled-together, un-tested,
simple Makefile that "might" do the job:

--------8<--------
crudasm1: crudasm1.cpp
gcc -c -o ../x86c/x86c_insn_names.o ../x86c/x86c_insn_names.c
gcc -c -o ../x86c/x86c_insn_name_search_table.o ../x86c/
x86c_insn_name_search_table.c
gcc -c -o ../x86c/x86c_insns.o ../x86c/x86c_insns.c
gcc -c -o ../x86c/x86c_encodings.o ../x86c/x86c_encodings.c
gcc -c -o ../x86c/x86c_decoder_table.o ../x86c/x86c_decoder_table.c
gcc -c -o ../x86c/decode.o ../x86c/decode.c
g++ -c -o asmwriter.o asmwriter.cpp
g++ -o crudasm1 crudasm1.cpp asmwriter.o ../x86c/decode.o ../x86c/
x86c_*.o

clean:
rm *.o
rm ../x86c/*.o

remove:
rm crudasm1
-------->8--------

I will test it tomorrow. ...or maybe someone here will script you a
better one if they aren't too busy testing the latest "Stdlib duo"
powered .net assembler.

Nathan.