On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote:
One specific question I have is: what's the difference between
-g and -debug and -d-debug?
-debug enables the `debug` keyword inside the D code itself. This
lets you bypass other rules temporarily. For example
void foo() pure {
writeln("called foo");
}
Normally, that wouldn't compile, since writeln is not pure. But
if you do
void foo() pure {
debug writeln("called foo");
}
It is allowed. Without the `-debug` switch, that line is just
ignored, it is not compiled. With the `-debug` switch, that line
is allowed - and it bypasses the pure restriction.
It does NOT do anything related to running D in debuggers like
gdb, it just enables code guarded by that debug keyword.
-g
-g is what compiles in the information gdb uses. This info is
used to print function names in stack traces, make breakpoints by
file and line number, etc.
You can use -g and -debug together or independently or whatever
depending on what exactly you want to do.
Now, some general tips on using D with gdb:
* Segfaults should be run inside the debugger to get the stack
trace. If your program did "Segmentation fault (core dumped)",
you can fire up gdb after the fact on it. Check that directory
for a .core file and then run `gdb program that.core` to inspect
it.
* Running a program in gdb may sometimes say "program received
SIGUSR1" and pause.
The commands
handle SIGUSR1 noprint
handle SIGUSR2 noprint
will skip this. SIGUSR1/2 are used by the GC when doing
collections so you probably don't care about it. You can put
those commands i your ~/.gdbinit to run every time.
* Running `gdb --args ./yourprogram --DRT-trapExceptions=0` will
break on any uncaught exception so you can inspect that stuff.
Super useful if you get one of those.
