On Wednesday, 13 January 2021 at 14:13:11 UTC, Adam D. Ruppe wrote:
>
> -debug enables the `debug` keyword inside the D code itself. This lets you bypass other rules temporarily. For example
>
> ...
>
> It does NOT do anything related to running D in debuggers like gdb, it just enables code guarded by that debug keyword.
>

Thanks, that's very clear.

> * 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.

It seems on my system no .core file gets generated, even though the program outputs "Segmentation fault (core dumped)". At least it's not present in the directory from where I compile and run the program, nor is it in /var/lib/systemd/coredump where, according to systemd-coredump's documentation, it should go by default. Anyway, I'm guessing this is a config problem with my Linux, rather than anything to do with D's compiler or runtime.

> * 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.

Yes! Excellent tips these. Thank you.

On Wednesday, 13 January 2021 at 14:13:17 UTC, evilrat wrote:
> if you are looking for back trace someone recently posted a hint for linux where there is no back trace by default is to import core.sys.linux.backtrace or something that has back trace info and using it in exception handler for runtime to print the stack trace.
> https://dlang.org/phobos/core_runtime.html#.defaultTraceHandler

Good tip, thanks.

On Wednesday, 13 January 2021 at 14:17:51 UTC, Rikki Cattermole wrote:
>
> Same thing.

Clear, thanks.

I'm just discovering today that DMD and LDC are two different compilers. I got a different impression from the following webpage, which claims that ldmd2 is a wrapper invoking ldc2.

https://stackoverflow.com/questions/35515138/ldc2-vs-ldmd2-whats-the-difference

Perhaps this is just a peculiarity of how D is distributed on Debian? I simply installed the 'ldc' package from Debian's official repos, and that contains both a binary called ldc2 and one called ldmd2.

On Wednesday, 13 January 2021 at 14:27:48 UTC, user1234 wrote:
>
> You really mostly only requires -g. Then you have to learn gdb.
> A few basis to get started

I've used GDB before, but I've forgotten nearly all of it. Your recap of the basics is appreciated. :-)

On Wed, Jan 13, 2021 at 4:10 PM Roguish via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> On Wednesday, 13 January 2021 at 14:17:51 UTC, Rikki Cattermole wrote:
> >
> > Same thing.
>
> Clear, thanks.
>
> I'm just discovering today that DMD and LDC are two different compilers. I got a different impression from the following webpage, which claims that ldmd2 is a wrapper invoking ldc2.
>
>
> https://stackoverflow.com/questions/35515138/ldc2-vs-ldmd2-whats-the-difference
>
> Perhaps this is just a peculiarity of how D is distributed on Debian? I simply installed the 'ldc' package from Debian's official repos, and that contains both a binary called ldc2 and one called ldmd2.
>

There are 3 main compilers which share same frontend,
DMD (using own backend), LDC2(llvm backend) a GDC(gcc backend)

ldmd and gdmd are some wrappers to make similar interface for compiling
with any of these compilers.
So generally dmd, gdmd and ldmd2(on some distribution ldmd without 2)
should have accept same args

So calling <dmd or gdmd or ldmd2> -arg1 -arg2 -arg3 should do the same but with different compilers behind the scene.