CODEWITHSUNDEEP
gdbnasm
kasterma
kasterma

Reputation: 4469

NASM & GDB: losing first instruction

I am learning assembler, and found some the following surprising. I essentially copied some hello world code from somewhere on the internet

section .text
    global  _start

_start:
    mov edx,len
    mov ecx,msg
    mov ebx,1
    mov eax,4
    int 0x80        ; interrupt for calling kernel

    mov eax,1
    int 0x80

section .data

msg db  'Hello, world!',0xa
len equ $ - msg

I compile and link this with nasm -f elf -g hellow.asm, ld hellow.o -o hellow. If I now load it into gdb I can list code and run it just fine. If I put a breakpoint on the first mov instruction the program does not stop there. Running ndisasm (ndisasm -b32 hellow) on the resulting file I get (the part I think is relevant):

0000007D  0000              add [eax],al
0000007F  00BA0E000000      add [edx+0xe],bh
00000085  B9A0900408        mov ecx,0x80490a0
0000008A  BB01000000        mov ebx,0x1
0000008F  B804000000        mov eax,0x4
00000094  CD80              int 0x80
00000096  B801000000        mov eax,0x1
0000009B  CD80              int 0x80

So the instruction does not appear.

I'd greatly appreciate a hint as to what is happening, or where to go find out about what is happening.

Upvotes: 3

Views: 604

Answers (1)

cthom06
cthom06

Reputation: 9635

The reason your instruction doesn't appear correctly in your disassembly is just an alignment issue of where it starts to disassemble and how the instructions happen to fall. Because x86 has variable length instructions, the disassembler needs to know an entry point. The correct listing is more like:

00000080  BA0E000000      mov edx,0xe ; I think
00000085  B9A0900408      mov ecx,0x80490a0
...

The real problem is with gdb it would seem, probably with how you're setting the breakpoint (plus, i can't recall if gdb chokes on breaking before the first instruction, I'd have to check).

Upvotes: 2

Related Questions