debuggingassemblygdb

How to start the program in step mode on a stripped executable?

I have an assembly program I wish to debug. If this program were assembled with symbols, I can just set a breakpoint at _start and after telling GDB to run it, it would break right away since _start is where the executable is defined to start.

However, suppose this program has had its symbols stripped. Then, it would be impossible to put a breakpoint at _start because that symbol no longer exists. While I could go trawling the executable's header to find the defined program start, it's an operation I'm used to enough that I'd expect GDB to have such an option to "run in single-stepping mode". Yet, I have found no information online about how to do that.

Solution

  • stepi and nexti (si and ni) to single-step by assembly instruction instead of source line.
    Use layout asm to show disassembly as you step (TUI mode),
    and/or usual commands like disas and x /i

    Use starti to start the process paused, before executing the first user-space instruction.
    This will normally be at _start of the dynamic linker, not the executable's own _start (ELF entry point) unless it's a static executable.

    So what you might actually want to do is info file (after starti so the process exists and there's a base address chosen by the kernel so addresses printed by GDB can be actual absolute addresses. GDB disables ASLR by default for a process started from within it, so Linux always picks 0x555... for PIE executables.)
    Then set a breakpoint there with b *address, using the numeric address.

    For example on x86-64 Arch GNU/Linux (with some verbosity trimmed out):

    $ gdb /bin/ls
(gdb) starti
Program stopped.
0x00007ffff7fe3dc0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) info file
...
Local exec file:
        `/usr/bin/ls', file type elf64-x86-64.
        Entry point: 0x555555559130
...
(gdb) b *0x555555559130
Breakpoint 1 at 0x555555559130
(gdb) c
Continuing.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, 0x0000555555559130 in ?? ()

    In TUI mode, you can hold shift to make mouse select work normally despite GDB having the terminal in a mode where plain left clicks and click+drag don't select like they normally do. (I using Konsole, KDE's xterm equivalent.)

    I'd guess that most of this would also work for Windows and macOS.