0

I have the following program, max.s, which finds the max of a list of numbers:

$ as max.s -g -o max.o && ld max.o -g -o max && ./max ubuntu$ echo $? 222

The code for the program is as follows:

.section .data data_items: .long 2,45,222,22,11,22,33,44,5,0 .section .text .globl _start _start: movl $0, %edi movl data_items(,%edi,4), %eax movl %eax, %ebx start_loop: cmpl $0, %eax je loop_exit incl %edi movl data_items(,%edi,4), %eax cmpl %ebx, %eax jle start_loop movl %eax, %ebx jmp start_loop loop_exit: movl $1, %eax int $0x80

What would be the proper way to run gdb on this program? In other words:

  1. Would I run gdb max.s or gdb max.o or gdb max ?
  2. If I type out "layout src", it says "No Source Available". However, if I then type l and do layout src again, it shows the source. Why is this so?

enter image description here

Improve this question
1
  • 1
    gdb max. You want to run the executable. Commented Oct 9, 2019 at 1:20

2 Answers 2

Reset to default
1

Would I run gdb max.s or gdb max.o or gdb max ?

Try it? Only the last command would actually work.

To debug a progra,, you need a program that can run. Since neither max.s, nor max.o are runnable, trying to debug them will result in an error of some sort when GDB tries to execve(2) the given program.

For max.s, you also likely to get an error from GDB saying it doesn't understand what to do with that file.

If I type out "layout src", it says "No Source Available". However, if I then type l and do layout src again, it shows the source. Why is this so?

That part I don't know. It may be a bug in the GDB TUI.

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

Comments

0

If I type out "layout src", it says "No Source Available"

You can always use layout reg to show registers + disassembly. Then you don't need to care about your assembler + linker including line numbers, just symbols for your labels. (Symbols help GDB know where to start disassembly from when you're stopped at an instruction that isn't the first after a label. x86 machine code can't unambiguously be decoded backwards).

The only reason you'd want source lines is to see your comments, but usually you have your editor in another window and for a small loop or block you know what you expect to happen. The comments are to let you get that picture into your head more quickly when you've been away from the code for a while, not so much when you've just written it / are still working on it. But if you do want a reminder on what's supposed to be in which register at a certain point, you can just flip to the source in your editor.

Disassembly is often more useful than the source. And it rules out classes of bugs like a macro definition that didn't work the way you thought, or a typo that becomes obvious once assembled + disassembled.

Use si and ni to single-step by instructions, not source lines.

b *0x1234 sets a breakpoint at a numeric address (which you can copy/paste from the disassembly), or just single-step to where you want a breakpoint and use b there.

See also the bottom of the x86 tag wiki for more tips on debugging asm. Especially using strace for any code that makes system calls.

as max.s -g -o max.o && ld max.o -g -o max

You can do that with one command: gcc -nostdlib -static -g max.s -o max. You might or might not find that easier. But if you have something that can assemble as 32 or 64-bit, being able to add one -m32 instead of adding different options for as and ld is handy. Or if you want to recall the same command and use it on a different source file, max.s only appears once. The biggest advantage is if you want to write a C test harness for your asm function, gcc -no-pie -fno-pie foo.c foo.S Just Works.

(I personally usually leave out the -o max part and just debug gdb ./a.out. But it's possible to get mixed up about which source your a.out came from that way.)

Improve this answer

Comments