gdb for assembly language

00x · 04-06-2020, 01:18 AM

Hi. I'm fairly new with assembly language (using nasm on ubuntu 64bit) and I'm having some trouble using gdb for debugging.
Right now I have a sandbox asm file that I put code into just to test to see how registers and stuff change in gdb before I try writing an actual program.
This isn't a program I need help with I just want to know why gdb is responding like it is.

(lines 1-8 are just comments)

Code:

9	SECTION .data			; Section containing initialized data
10	
11	SECTION .bss			; Section containing uninitialized data
12	
13	SECTION .text			; Section containing code
14	
15	
16	global _start			; Linker needs this to find the entry point!
17	
18	_start:
19	   nop				; This no-op keeps gdb happy
20	
21	; put test code below {{{
22	
23	mov eax, "WXYZ"
24	
25	mov ebp,esi
26	mov bl,ch
27	add di,ax
28	add ecx,edx
29	mov ax,067FEh
30	xchg cl,ch
31	
32	; }}} put test code above
33	
34	nop
35	
36	; clean up
37	   mov eax,1			; Specify Exit syscall
38	   mov ebx,0			; Return a code of zero
39	   int 80H			; Make syscall to terminate program

Here is gdb output when I try just simple break and print commands:

Code:

(gdb) break 23
Breakpoint 1 at 0x400082: file sandbox.asm, line 23.
(gdb) run
Starting program: /home/gucci/CODE.d/ASMBLY.d/sandbox.d/sandbox 
[Inferior 1 (process 26302) exited normally]

Why doesn't it break? It does this for break 25, 29 and 30 as well

Only on line 26 can I successfully add a break

Code:

(gdb) break 26
Breakpoint 3 at 0x400090: file sandbox.asm, line 26.
(gdb) run
Starting program: /home/gucci/CODE.d/ASMBLY.d/sandbox.d/sandbox 

Breakpoint 3, 0x0000000000400090 in _start ()

When I add a break at 28 I get a segfault when I try running, why?

Code:

(gdb) b 28
Breakpoint 7 at 0x40009a: file sandbox.asm, line 28.
(gdb) run
Starting program: /home/gucci/CODE.d/ASMBLY.d/sandbox.d/sandbox 

Program received signal SIGSEGV, Segmentation fault.
0x00000000004000a2 in ?? ()

The program does not segfault if I just run it normally (`$ ./sandbox')

Also I am assembling with `nasm -f elf64 -g -F stabs sandbox.asm'
(The book I am working from is for 32bit but I am on a 64bit cpu)
but when I try to run `$ gdb -tui sandbox' it won't show the source code, I have to open the source code in a separate terminal and work from those line numbers.
However when I try `ddd sandbox' ddd will open sandbox.asm in it's source code window.

Any help would be appreciated,
Thanks.

00x · 04-06-2020, 04:34 AM

Just in case anyone was interested, I realized the problem was that I had forgotten that when setting a breakpoint at say line 26, the debugger stops execution at line 25!

The segfaults are caused I think by add, xchg and `mov ax,067FEh' (I just copied these straight from the book I'm reading)

And the reason gdb isn't stopping at the breakpoints I'm setting and instead just runs straight through the program, is because gdb just gives the illusion that it is debugging with the source code, but it is instead working off machine code. Therefore `nops' need to be added,

Code:

...
	nop
	mov eax, "WXYZ"
	nop			; put the breakpoint on this line to pause at the line above it
	mov ebp,esi
	nop
...

rtmistler · 04-06-2020, 06:48 AM

I have a moderate amount of experience with gdb, but solely with C source.

Your second comment mentions line 26, but your original comment cites line 23 which should be before the fault.

I can understand that for assembly it doesn't follow the source file lines. And then it seems to accept the setting of a breakpoint...

Why do you say it won't print out those source lines? They should be easier to see because when they show in the debugger in assembly, they're obviously matching 100% what your file shows.

You can use 'b' as opposed with typing out 'break'.

You can use 'l' to 'list' the area in your source near or about where it thinks the program counter presently is located, or near a source line.

Like you can just type 'l' or 'list' or you can also type 'l 25' or 'list 25' and that should show you source line #25, but for C code is where I'm more familiar.

Listing the source doesn't work?

SoftSprocket · 04-06-2020, 07:57 AM

In my experience, which is limited, gdb isn't terribly assembler friendly. Still, I took your code, removed the nop since it shouldn't be necessary, and compiled it with yasm and it worked as expected. I use yasm, and with yasm, to use gdb you have to indicate a debugging format. i.e.

Code:

yasm -f elf64 -g dwarf2 -l forum_test1.lst -o forum_test1.o forum_test1.asm

This allowed me to set breakpoints and so forth.

I then linked with ld.

There are two debugging formats dwarf and stabs but I think dwarf has mostly replaced stabs.