Linux (64-bit), nasm and gdb

Question

I was searching other threads without luck. My problem is perhaps simple but frustrating. I'm compiling two files on 64-bit Ubuntu 11.04:

1. nasm -f elf64 -g file64.asm
2. gcc -g -o file file.c file64.o

Then I debug the resulting executables with gdb. With C, everything is OK. However, when debugging assembly, the source code is "not visible" to the debugger. I'm getting the following output:

(gdb) step
Single stepping until exit from function line,
which has no line number information.
0x0000000000400962 in convert ()

A quick investigation with:

objdump --source file64.o

shows that the assembly source code (and line information) is contained in the file.

Why can't I see it in a debug session? What am I doing wrong? These problems arose after moving to 64-bit Ubuntu. In the 32-bit Linux it worked (as it should).

Answer 1

With NASM, I've had much better experience in gdb when using the dwarf debugging format. gdb then treats the assembly source as if it were any other language (ie, no disassemble commands necessary)

nasm -f elf64 -g -F dwarf file64.asm

(Versions 2.03.01 and later automatically enable -g if -F is specified.)

I'm using NASM version 2.10.07. I'm not sure if that makes a difference or not.

Answer 2

For anyone else stuck with the broken things on NASM (the bug is not fixed so far): just download the NASM git repository and switch to version 2.7, which is probably the last version that works fine, ie supports gdb. Building from source this outdated version is only a workaround (you don't have support for the last ISA for example), but it's sufficient for most students.

Answer 3

GDB is a source-level (or symbolic) debugger, which means that it's supposed to work with 'high-level programming languages' ... which is not you're case!

But wait a second, because, from a debugger's point of view, debugging ASM programs is way easier than higher level languages: there's almost nothing to do! The program binary always contains the assembly instruction, there're just written in their machine format, instead of ascii format.

And GDB has the ability to convert it for you. Instead of executing list to see the code, use disassemble to see a function code:

(gdb) disassemble <your symbol>
Dump of assembler code for function <your symbol>:
   0x000000000040051e <+0>: push   %rbp
   0x000000000040051f <+1>: mov    %rsp,%rbp
=> 0x0000000000400522 <+4>: mov    0x20042f(%rip),%rax        
   0x0000000000400529 <+11>:    mov    %rax,%rdx
   0x000000000040052c <+14>:    mov    $0x400678,%eax
   0x0000000000400531 <+19>:    mov    %rdx,%rcx

or x/5i $pc to see 5 i nstruction after your $pc

(gdb) x/5i $pc
=> 0x400522 <main+4>:   mov    0x20042f(%rip),%rax
   0x400529 <main+11>:  mov    %rax,%rdx
   0x40052c <main+14>:  mov    $0x400678,%eax
   0x400531 <main+19>:  mov    %rdx,%rcx
   0x400534 <main+22>:  mov    $0xc,%edx

then use stepi ( si ) instread of step and nexti ( ni ) instead of next .

display $pc could also be useful to print the current pc whenever the inferior stops (ie, after each nexti / stepi .

Answer 4

GDB might not know where to search for your source files. Try to explicitly tell it with directory .