2
votes

I have only recently started learning assembly (NASM). The book I am learning from was written for 32bit cpu but my computer is a 64bit.

I have a `sandbox.asm' file that I put code into and then after assembling I run the program in gdb to see register values and what is going with each line etc.

Sometimes I get errors with gdb that I don't understand.

Here is my sandbox.asm:

1   section .data
2   section .text
3   
4       global _start
5   
6   _start:
7       nop
8   ; test code below
9   mov rax,5
10  mov rbx,3
11  mul rbx
12  ; test code above
13      nop
14  
15  section .bss

A simple enough program, 5 should go into rax, 3 into rbx, and the result should end up in rdx and rax.

But instead gdb runs off to the end and only stops at 1 breakpoint (not sure if it is even doing that or stopping at the `nop').

$ gdb sandbox
(gdb) b 9
Breakpoint 1 at 0x400082: file sandbox.asm, line 9.
(gdb) b 10
Breakpoint 2 at 0x40008c: file sandbox.asm, line 10.
(gdb) b 11
Breakpoint 3 at 0x400096: file sandbox.asm, line 11.
(gdb) r
Starting program: /home/gucci/CODE.d/ASMBLY.d/sandbox.d/sandbox 

Breakpoint 2, 0x000000000040008c in _start ()
(gdb) i r
rax            0xcc 204
rbx            0x3  3
[...]
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000000000040008f in ?? ()
(gdb) i r
rax            0x264    612
rbx            0x3  3
[...]
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Where does 204 come from? At least 3 is multiplying with it and putting the result in rax (612).

Why do I get a segfault as well? I tried using registers 32bit (eax), 16bit (ax) and even 8 bit registers for the `mov' instructions but gdb didn't work well at all with them.

Also `$ gdb -tui sandbox' doesn't work even when the source file is in the same directory, so I have gdb open in one terminal and the code open in ed in another.

Is there a better debugger that is specially for assembly (rather than for c like gdb)?

1
Note you can stepi (aka si) to single-step by instructions, and use disas. (Or layout reg). Then you don't need any debug info. You can start the program in a paused state with starti (to stop before the first user-space instruction at _start). See asm debug tips at the bottom of stackoverflow.com/tags/x86/infoPeter Cordes

1 Answers

3
votes

Sorry for posting, I just found the solution.

My previous makefile was:

1   sandbox: sandbox.o
2       ld -o sandbox sandbox.o
3   sandbox.o: sandbox.asm
4       nasm -f elf64 -g -F stabs sandbox.asm

but now I have changed it to:

1   sandbox: sandbox.o
2       ld -o sandbox sandbox.o
3   sandbox.o: sandbox.asm
4       nasm -f elf64 -g -F dwarf sandbox.asm

That `dwarf' command makes awhole WORLD of difference!

Now gdb is behaving like I expect it to.