Re: How to debug D on Linux
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 -arg1 -arg2 -arg3 should do the same but with different compilers behind the scene.
Re: How to debug D on Linux
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. :-)
Re: How to debug D on Linux
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.
Re: How to debug D on Linux
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.
Re: How to debug D on Linux
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.
Re: How to debug D on Linux
On Wednesday, 13 January 2021 at 14:13:07 UTC, drug wrote: Short answer - sometimes the compiler does not emit a stackframe (due to optimization for example). OK, so -gs prevents a certain optimization that would make debugging harder in certain situations. Thanks for clearing that up.
Re: How to debug D on Linux
On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote: On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote: Anything else I need to know when debugging on Linux, without an IDE? One specific question I have is: what's the difference between -g and -debug and -d-debug? Also, what does it mean to "always emit a stackframe" (compiler option -gs) ? -g : generate dwarf info, the debug info, the most important -debug : compiles the debug statements, e.g debug logging. not so important, this is a conditional compilation feature. -gs: always emit a prelude/prologue. but dmd pretty much always do that even when not required (sigh). You really mostly only requires -g. Then you have to learn gdb. A few basis to get started, a session for a segfault is often like $ gdb ./myapp $ run and when it crashes, note the source position, additionally $ bt $ p somevar $ p some.more.complex.expression may already give interesting infos. If not, during a second session you will rather put breakpoints to see what happens before the access violation and step from that breakpoint to the code that accesses unowned memory. $ gdb ./myapp $ break .d $ run and then step by step, each time it pauses you inspect the interesting stuff. Note that I may be wrong on the syntax of the commands as I always use an IDE GUI.
Re: How to debug D on Linux
On Wednesday, 13 January 2021 at 13:47:55 UTC, Roguish wrote: On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote: Anything else I need to know when debugging on Linux, without an IDE? One specific question I have is: what's the difference between -g and -debug and -d-debug? From LDC (ldc specific): --d-debug[=] - Compile in debug code >= or identified by --d-version= - Compile in version code >= or identified by From dmd: -debugcompile in debug code -debug=compile in debug code <= level -debug=compile in debug code identified by ident -version= compile in version code >= level -version= compile in version code identified by ident Same thing.
Re: How to debug D on Linux
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 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? no idea what is -d-debug, but -g will emit debug info for debugger, and -debug will turn on certain features such as contracts and asserts even in release builds.
Re: How to debug D on Linux
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.
Re: How to debug D on Linux
On 1/13/21 4:47 PM, Roguish wrote: Also, what does it mean to "always emit a stackframe" (compiler option -gs) ? Short answer - sometimes the compiler does not emit a stackframe (due to optimization for example). In general if you are able to debug your binary by gdb then you don't need to worry this flag. I skip long answer, sorry :-) But you can google about stack frame.
Re: How to debug D on Linux
On 1/13/21 4:47 PM, Roguish wrote: On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote: Anything else I need to know when debugging on Linux, without an IDE? One specific question I have is: what's the difference between -g and -debug and -d-debug? Also, what does it mean to "always emit a stackframe" (compiler option -gs) ? https://stackoverflow.com/questions/17392200/debugging-dmd-generate-program-through-gdb
Re: How to debug D on Linux
On Wednesday, 13 January 2021 at 13:30:48 UTC, Roguish wrote: Anything else I need to know when debugging on Linux, without an IDE? One specific question I have is: what's the difference between -g and -debug and -d-debug? Also, what does it mean to "always emit a stackframe" (compiler option -gs) ?
Re: How to debug D on Linux
On Wednesday, 13 January 2021 at 13:22:01 UTC, Roguish wrote: How to debug D? be possible to get at least a stack trace? I've discovered that GDB works with the binary generated by the D compiler, so that's great. Anything else I need to know when debugging on Linux, without an IDE?
How to debug D on Linux
How to debug D? My little trial app gives a segmentation fault. Probably a null pointer somewhere, which I could find simply by reading my code. But I'm puzzled that the program outputs very little helpful info when it crashes, even though I've compiled with all the debug options I could find in the docs: -g -gs -gf -debug -d-debug Still all I get at runtime is Segmentation fault (core dumped) Surely it should be possible to get at least a stack trace?
