How to debug D on Linux

[Adam D. Ruppe]

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.