fetag wrote:
> hello, All:
> I have a little puzzle on NASM, I write a very simple case:
> [bits 32]
> segment .text
> global _start
> _start:
> mov eax, 4
> mov ebx, 2
> ret
> then, compiled it as:
> C:\ASM>nasm first.asm -o first.exe -l first.lst
> but, When I disassembling the first.exe, I get the code like this:
> C:\ASM>ndisasm -b 32 first.exe
> 00000000 B8 db 0xB8
> 00000001 0400 add al,0x0
> 00000003 0000 add [eax],al
> 00000005 BB02000000 mov ebx,0x2
> 0000000A C3 ret
> My question is: where the mov eax,0x4 in disassembly code? and where
> the two add statements come from? where the "00000000
> B8 db 0xB8" come from?
> Thank you all!
Hi Fetag,
I can't duplicate this, either. Ndisasm will produce some very puzzling
results if you don't "do it right", but I'd expect what you've done to
work! I've used a *lot* of versions of nasm/ndisasm, and never seen it
do *that*, exactly...
But I wonder what in hell you're trying to do! "start_", and "bits 32"
look like maybe a Linux executable... But the command line you're giving
Nasm will produce a flat binary. You can name the output file ".exe",
but it won't be any known executable format. I mention that because some
people start out with "nasm -o myfile.com myfile.asm" (which will work,
since Nasm's default output format is "-f bin... in a "normal" build,
this *can* be changed easily). Then they swap to "-o myfile.exe" or "-o
myfile.obj", and don't add an "-f switch". Won't work - you just get a
flat binary file named ".exe"!
"global" doesn't do anything in bin mode, so I'm confused. We *can* get
an executable for Windows or Linux out of "-f bin" mode, but it requires
an executable header stuck on the front. "_start" would be the default
entrypoint for Linux, but it's jumped to, not called, so "ret" won't end
cleanly. "ret" will work for a PE (I think), but you'd want to preserve
ebx (and esi, edi, ebp... but you don't alter them in this code).
Obviously not intended to be a "useful" executable, but I wonder what
you're working towards...
None of that explains the weird behavior from ndisasm. I can produce
exactly the results you show by adding "-s1" to ndisasm's command
line... I doubt if you've done that...
Good puzzle! Hope you'll post the answer...
Best,
Frank
P.S. Anyone using "early 64-bit Nasm" should probably upgrade. 0.98.39
was pretty stable, but there are known glitches in 0.99 through... well,
we *think* 2.02 is okay..
http://nasm.sf.net
|
