11

I'm running on Ubuntu 12.10 64-bit.

I am trying to debug a simple assembly program in GDB. However, GDB's GUI mode (-tui) appears to be unable to locate the source code of my assembly file. I've rebuilt the project in the current directory and searched Google to no avail.

My commands:

nasm -f elf64 -g -F dwarf hello.asm gcc -g hello.o -o hello gdb -tui hello

Debug information appears to be loaded; I can set a breakpoint at main(), but the top half of the screen still displays '[ No Source Available ]'.

Here is hello.asm if you're interested:

; hello.asm a first program for nasm for Linux, Intel, gcc ; ; assemble: nasm -f elf -l hello.lst hello.asm ; link: gcc -o hello hello.o ; run: hello ; output is: Hello World SECTION .data ; data section msg: db "Hello World",10 ; the string to print, 10=cr len: equ $-msg ; "$" means "here" ; len is a value, not an address SECTION .text ; code section global main ; make label available to linker main: ; standard gcc entry point mov edx,len ; arg3, length of string to print mov ecx,msg ; arg2, pointer to string mov ebx,1 ; arg1, where to write, screen mov eax,4 ; write command to int 80 hex int 0x80 ; interrupt 80 hex, call kernel mov ebx,0 ; exit code, 0=normal mov eax,1 ; exit command to kernel int 0x80 ; interrupt 80 hex, call kernel
Improve this question
4
  • Deleted see answer below for reason. Commented Dec 25, 2012 at 4:54
  • 1
    A program produced by an assembler does not have debug info. The compiler (e.g. gcc -g) is producing debug info as assembler directives or constructs. So your question does not have real sense. However, gdb is able to run once at a time, step by step, machine instructions. Commented Dec 25, 2012 at 8:22
  • Do you have any solutions for this? Commented Jan 2, 2015 at 19:39
  • For googlers: stackoverflow.com/questions/27747556/… Commented Jan 2, 2015 at 20:18

2 Answers 2

Reset to default
8

This statement is false.

The assembler does produce line number information (note the -g -F dwarf) bits.

On the other hand he assembles what is obviously 32-bit code as 64 bits, which may or may not work.

Now if there are bugs in NASM's debugging output we need to know that.

A couple of quick experiments shows that addr2line (but not gdb!) does decode NASM-generated line number information correctly using stabs but not using dwarf, so there is probably something wrong in the way NASM generates DWARF... but also something odd with gdb.

GNU addr2line version 2.22.52.0.1-10.fc17 20120131, GNU gdb (GDB) Fedora (7.4.50.20120120-52.fc17)).

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Hmm. What kind of tests should I perform to narrow down the problem?
6

The problem in this case is that the assembler isn't producing line-number information for the debugger. So although the source is there (if you do "list" in gdb, it shows a listing of the source file - at least when I follow your steps, it does), but the debugger needs line-number information from the file to know what line corresponds to what address. It can't do that with the information given.

As far as I can find, there isn't a way to get NASM to issue the .loc directive that is used by as when using gcc for example. But as isn't able to take your source file without generating a gazillion errors [even with -msyntax=intel -mmnemonic=intel -- you would think that should work].

So unless someone more clever can come up with a way to generate the .loc entries which gives the debugger line number information, I'm not entirely sure how we can answer your question in a way that you'll be happy with.

Improve this answer

3 Comments

Thanks. I'm filing a bug report with NASM.
funny. I had the same problem as the OP with a c program and gdb text ui. I hit list and everything seems to work when I just hit typed list command.
@IrresponsibleNewb did you file the bug report? Link?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.