Skip to content

Latest commit

 

History

History
84 lines (60 loc) · 4.78 KB

GDB.md

File metadata and controls

84 lines (60 loc) · 4.78 KB

GDB

Execution

Run a program through gdb:
gdb ./a.out
With parameters:
gdb --args ./a.out arg1 arg2 ...
To "run" it right away:
gdb -ex run ./a.out or gdb -ex run --args ./a.out arg1 arg2 ... with params.
To "run" the program but stop at temporary breakpoint at main().
gdb -ex start ./a.out
Use starti instead if you want to run and stop at the very first instruction.
To use a "gdb-script" along with launching gdb:
gdb -x somefile ./a.out
To attach gdb to an already started program using its pid:
gdb -p $SOMEPID

Commands

Mains

  • r or run to run your program.
  • bt or backtrace.
  • q or quit.

Command Files

Some cool commands documentations:

Source directory settings are used with commands that involve source code, such as list, break, or step:

Navigations

l or list to list source code lines (10 by default) around the current line of execution.
It'll prefer source code provided in priority, but if it does not contain debug informations or of a compiled library will display the disassembly of the machine instructions.
Upon several consecutive execution of the list command, will continue scroll down the sources.
It also can be used with a line number or function name as an argument to list the source code around a specific location in the program.

Disassemble

To disassemble (or disass) a function or a range of addresses:

(gdb) disassemble function_name
(gdb) disassemble start_address, end_address

Attaching

TODO: explore: There might be some limitation to use GDB this way since the program was not launched within gdb virtual environnement.

TODO: clean following Claude response:
BEGIN
There are a few key differences between using the attach command in GDB to attach to a running process, versus running the binary directly within GDB:

  1. Startup State: When you run the binary directly within GDB, the program starts from the beginning, and you can set breakpoints, step through the code, etc. from the very start. When you attach to a running process, the program is already running, so you can only interact with it from its current state.
  2. Debugging Capabilities: When you run the binary within GDB, you have full access to all of GDB's debugging capabilities, such as setting breakpoints, stepping through the code, inspecting variables, etc. When you attach to a running process, some of these capabilities may be limited, depending on the state of the process.
  3. Process Control: When you run the binary within GDB, you have full control over the process, including the ability to pause, resume, and terminate it. When you attach to a running process, your control is more limited - you can pause and resume the process, but you generally can't terminate it directly from GDB.
  4. Startup Environment: When you run the binary within GDB, you can control the environment in which the program runs, such as setting environment variables, working directory, command-line arguments, etc. When you attach to a running process, you're limited to the environment that the process was already running in. In general, running the binary directly within GDB is the preferred approach when you have the ability to do so, as it gives you the most control and visibility over the program's execution. However, attaching to a running process can be useful in situations where you need to debug a program that is already running, or where you don't have the ability to run the program directly within GDB.

END

Configuration

You can alias alias gdb='gdb -q' somewhere, so you wont have the welcome message everytime.

In your working directory (your project for example), you can make a file called .gdbinit containing a "gdb-script" which will be executed by running the command gdb.

Docs

https://developer.apple.com/library/archive/documentation/DeveloperTools/gdb/gdb/gdb_toc.html