1

I am starting to program linux x86_64 assembly code, and thus I was trying to debug just like one would normal C code, for examble when I run gdb -tui ./a.out, I get my source code and I can then toggle the registers to see what's going on, and go step by step, etc.

However that is not the case when I use it with assembly binaries, I simply get [ No Source Available ]. However I can see the registers and the resulting assembly code (given I do layout next). The thing is, since I am using C functions in the middle of my code (mainly printf, in order to simplify the IO process, as instructed by my professor); I would like to see my original assembly code. At the moment I have installed:

  • gcc :(GCC) 12.2.0

  • ld :GNU ld (GNU Binutils) 2.39.0

  • NASM version 2.15.05

And to compile and run a program I run:

nasm -f elf64 -o hello.o hello.asm
gcc hello.o -o hello -no-pie 
gdb ./hello

Those were the commands that my teacher told us to run. I have read online that I could pass the -g flag to gcc to debug my code; it compiles just fine, but I can't see my source code either. I have also tried passing -g to nasm (same issue, compiles but no source code)

Is there a flag/setting that I'm not passing?

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
  • 2
    Does this answer your question? [How can I include debug information with nasm?](https://stackoverflow.com/questions/27747556/how-can-i-include-debug-information-with-nasm) – sj95126 Oct 06 '22 at 22:39
  • Hi! I have seen that answer but it hasn't worked on my machine. Like I said on the question I am running a 64 bit system, that answer only applies to 32 bit systems. So it would be `nasm -f elf -g -F stabs hello.asm`. Plus, that answer is not using C functions in the middle of the assembly code, but rather pure assembly – CrazyBrocoli Oct 06 '22 at 22:49

1 Answers1

2

Just tell NASM to compile the source code with -g to add debugging symbols:

nasm -g -f elf64 -o hello.o hello.asm
gcc -m64 hello.o -o hello -no-pie
gdb hello

Once GDB opens, you can display the source code with list:

Reading symbols from hello...
(gdb) list
1           extern  printf          ; the C function, to be called
2   
3           section .data           ; Data section, initialized variables
4   msg:    db "Hello world", 0     ; C string needs 0
5   fmt:    db "%s", 10, 0          ; The printf format, "\n",'0'
6   
7           section .text           ; Code section.
8   
9           global main             ; the standard gcc entry point
10  main:                           ; the program label for the entry point

Here is a sample source code:

; Declare needed C  functions
        extern  printf          ; the C function, to be called

        section .data           ; Data section, initialized variables
msg:    db "Hello world", 0     ; C string needs 0
fmt:    db "%s", 10, 0          ; The printf format, "\n",'0'

        section .text           ; Code section.

        global main             ; the standard gcc entry point
main:                           ; the program label for the entry point
        push    rbp             ; set up stack frame, must be aligned
    
        mov rdi,fmt
        mov rsi,msg
        mov rax,0               ; or can be  xor  rax,rax
        call    printf          ; Call C function

        pop     rbp             ; restore stack 

        mov rax,0               ; normal, no error, return value
        ret                     ; return
karlphillip
  • 92,053
  • 36
  • 243
  • 426
  • Hi karl! Thank you so much for your answer. I had never tried the -m64, first time I see it. Howevery, I followed your instructions and I got the following error: `No symbol table is loaded. Use the "file" command.` – CrazyBrocoli Oct 06 '22 at 22:51
  • 1
    @CrazyBrocoli : I suspect you may be encountering this known problem: https://stackoverflow.com/questions/72694342/gdb-does-not-load-source-lines-from-nasm and reported to bug tracking here: https://bugzilla.nasm.us/show_bug.cgi?id=3392798 . Are you using NASM 2.15.05? – Michael Petch Oct 06 '22 at 22:54
  • Yes, I am indeed. Thank you so much for this bug, I was not aware of it's existence. In the answer the user said "I manually went in and edited this value, and suddenly, I can debug the previously broken executable just fine.". How was the binary file changed? Or am I misinterpreting something? – CrazyBrocoli Oct 06 '22 at 23:01
  • Downgrading did not work, same issue – CrazyBrocoli Oct 06 '22 at 23:13
  • @karlphillip What NASM version are you using? It seems to be working on your machine – CrazyBrocoli Oct 06 '22 at 23:14
  • @MichaelPetch. `nasm --version` output: `NASM version 2.14.02 compiled on Jan 22 2019`. My commands: `nasm -g -f elf64 -o hello.o hello.asm`, `gcc -m64 hello.o -o hello -no-pie`. Once inside gdb I get a DIFFERENT error (so that's progress...maybe): `../sysdeps/x86_64/start.S: No such file or directory` – CrazyBrocoli Oct 06 '22 at 23:18
  • Both produce the same: I can't see my source code and I get the following error: `../sysdeps/x86_64/start.S: No such file or directory.` I should point out, I realized that I am able to see my source code if I only use assembly code and compile it with ld. However I am required to use C functions in my code. I hope that gives some perspective to the issue – CrazyBrocoli Oct 06 '22 at 23:24
  • Yes I can set a breakpoint on main. That seems to work. I get the memory address of the main function, and after run the program stops. Thing is, what is it that you mentioned about C debug file? I can run and debug "pure" C code just fine. (I can see the source and everything, normal gdb behavior) – CrazyBrocoli Oct 06 '22 at 23:34
  • I can see layout asm just fine, that appears to be the compiled code (not my own assembly code with the c functions calls). layout src displays the [ No source code ] error message – CrazyBrocoli Oct 06 '22 at 23:39
  • My apologies. You are totally right, i will edit my comment. I only call C functions, nothing else – CrazyBrocoli Oct 06 '22 at 23:42
  • 1
    @CrazyBrocoli : in that question I referred you to earlier about this bug, I discovered there is a proper NASM patch that fixes the problem and is an update to 2.15.05. I have managed to reproduce the issues you are seeing on my Ubuntu 22.04 system (I think you are using 22.10?). Source debugging of NASM objects is pooched. Download this DEB package https://github.com/iglosiggio/nasm/releases/download/nasm-2.15.05-2/nasm_2.15.05-2_amd64.deb then install it with `sudo dpkg -i nasm_2.15.05-2_amd64.deb` . When you assemble with nasm use `-g -F dwarf` (don't use `stabs`) – Michael Petch Oct 07 '22 at 01:04
  • Hello there Michael, thank you for your response. I am currently running Arch Linux, I do not think I can run that deb package. Maybe it is available from an Arch Repository – CrazyBrocoli Oct 07 '22 at 01:52
  • 1
    @CrazyBrocoli : I'm sorry I made a bad assumption. The source for the new patched version is here: https://github.com/iglosiggio/nasm/archive/refs/tags/nasm-2.15.05-2.tar.gz – Michael Petch Oct 07 '22 at 01:59
  • On the contrary Michael, your help has been beyond key. I should've clarified my distribution from the very beginning – CrazyBrocoli Oct 07 '22 at 02:26
  • 1
    @CrazyBrocoli No problem. You should be able to build it with `./autogen.sh` `./configure --prefix=/usr/local` and then `make` . `make install` to install it. If it fails on the documentation you can still manually copy the `nasm` executable manually to where you wish it installed. – Michael Petch Oct 07 '22 at 02:28
  • 1
    IT WORKS!!!! IT ACTUALLY WORKS! I symlinked the executable file. Thank you so so much Michael. Now the question is: - Why is this fix not on the normal version of nasm - What can I do in order to push for this change? - Please, if you could take the time, could you write this down as an anwer? As in a brief summary of all the trouble we (and specially, **you** have been through). You more than deserve the "correct answer mark" – CrazyBrocoli Oct 07 '22 at 02:55
  • @CrazyBrocoli : No problem. Since this information was already in an answer to a question I linked I think it would make sense to simply mark this as a duplicate. – Michael Petch Oct 07 '22 at 03:18