[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