[fpc-devel] fixing/extending dwarf support // Re: RECENT Commit breaking FpDebug - Dwarf / and not even fully fixing the original issue
Graeme Geldenhuys
mailinglists at geldenhuys.co.uk
Thu Apr 30 18:52:49 CEST 2026
On Thursday, 30 April 2026 15:35:38 BST Martin Frb via fpc-devel wrote:
> I was thinking about a tool (maybe to be included in automated testing)
> that could run gdb and lldb on given test-code (including compiling that
> code).
> And then inject commands like "p MyObject^" and regex the output for
> known field-names and -value (the formatting of those doesn't matter,
> only the presence).
>
> If that is of interest I may further look into it.
GDB already has that built-in. I've used it extensively in my projects for
automated tests.
There are two primary ways to do this: using the `-ex` flag for quick commands
or the `-x` flag for script files.
Example: Run a program, print a variable, and exit
$> gdb -batch -ex "break main" -ex "run" -ex "print my_variable" -ex "bt" ./
my_program
* `-batch`: Exit after commands are done.
* `-ex "break main"`: Set a breakpoint at main.
* `-ex "run"`: Start execution.
* `-ex "print my_variable"`: Inspect the value.
* `-ex "bt"`: Print a backtrace.
Using `-x` (Command Files)
--------------------------
If you have a long list of breakpoints, watchpoints, and print statements,
putting them in a text file is much cleaner.
Step 1: Create a command file (e.g., `debug_script.gdb`)
----[gdb]----
set pagination off
break main
break process_data
run
# Wait until we hit the second breakpoint
continue
print current_status
info locals
bt
quit
-----
NOTE: `set pagination off` is critical for batch mode so that GDB doesn't stop
and ask you to "Press enter to continue" when printing long outputs.
Step 2: Run GDB with the script
$> gdb -batch -x debug_script.gdb ./my_program
Regards,
Graeme
More information about the fpc-devel
mailing list