dbx
Debug programs
TLDR
Create a new dbx project in the current working directory
Sync local files from the specified path to DBFS and watch for changes
Deploy the specified workflow to artifact storage
Launch the specified workflow after deploying it
SYNOPSIS
dbx [options] [executable [corefile | process_id]]
PARAMETERS
-c file
Executes dbx commands from the specified file before accepting user input.
-I directory
Adds directory to the list of directories dbx searches for source files.
-P process_id
Attaches dbx to a running program identified by process_id.
-q
Suppresses the initial dbx banner and copyright message.
-V
Displays the dbx version information and exits.
-r
Runs the executable immediately upon dbx startup.
executable
The name of the program to be debugged. This program must be compiled with debugging information (e.g., using `gcc -g`).
corefile
The name of a core dump file to analyze post-mortem.
process_id
The process ID of a running program to attach to.
DESCRIPTION
dbx is a command-line symbolic debugger used primarily for C, C++, and Fortran programs. Originating from UC Berkeley, it became a prominent debugging tool, especially on Unix-like operating systems, most notably Sun Microsystems' Solaris. It allows developers to control program execution, inspect variables, set breakpoints, and trace program flow to identify and fix bugs.
While dbx provides a comprehensive set of debugging features, its prevalence on modern Linux distributions is limited. The open-source GNU Debugger (gdb) has largely superseded it as the standard debugger for most Linux development environments due to its wide availability, active development, and integration with the GNU toolchain. However, dbx might still be encountered in legacy systems, environments using specific commercial compilers (like Oracle/Sun Studio), or specialized embedded systems. Its command set is generally similar to gdb, making the transition for experienced users relatively straightforward, though specific syntax and capabilities may differ.
CAVEATS
dbx is not a standard utility on most modern Linux distributions. Its primary use is often tied to specific commercial Unix compilers (like Sun Studio/Oracle Developer Studio) or legacy systems. For general Linux development, gdb is the widely adopted and recommended debugger. Compatibility and feature sets can vary significantly between dbx versions.
COMMON <B>DBX</B> COMMANDS
- run: Starts the execution of the program.
- cont: Continues execution from the current point.
- next: Executes the next source line, stepping over function calls.
- step: Executes the next source line, stepping into function calls.
- stop at line_number: Sets a breakpoint at the specified line number.
- stop in function_name: Sets a breakpoint at the entry point of a function.
- print variable: Displays the value of a variable.
- where or trace: Displays the current stack trace.
- list: Displays source code around the current execution point.
- quit: Exits dbx.
DEBUGGING WORKFLOW
- Compile your program with debugging information (e.g., `gcc -g myprogram.c -o myprogram`).
- Start dbx: `dbx myprogram`.
- Set breakpoints (e.g., `stop at main.c:25`).
- Run the program (`run`).
- When a breakpoint is hit, inspect variables (`print myvar`), step through code (`next`, `step`), or view the call stack (`where`).
- Continue execution (`cont`) or quit (`quit`).
HISTORY
dbx originated at the University of California, Berkeley, in the late 1970s and early 1980s as part of the BSD Unix development. It quickly gained popularity as a robust symbolic debugger. Sun Microsystems adopted and further developed dbx as a core component of its SunOS and later Solaris operating systems and their associated developer toolchains (SunPro, later Sun Studio, now Oracle Developer Studio). While it remained prominent in the Solaris ecosystem, its adoption on Linux has been limited, largely due to the rise and widespread adoption of the open-source gdb by the GNU project, which offered similar capabilities and was freely available alongside the GCC compiler.