End user experience with D

[Adam D. Ruppe]

On Monday, 2 September 2013 at 12:00:43 UTC, Paolo Invernizzi 
wrote:
> ability to set a break (usually that's work, at least in OSX), 
> AND being able to inspect locals.

Here's what happens with me:

dmd test30.d -debug -gc
gdb test30
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
[...]
This GDB was configured as "x86_64-slackware-linux".
[...]
(gdb) break test30.d:13
Breakpoint 1 at 0x8070846: file test30.d, line 13.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, _Dmain () at test30.d:13
13              assert(0, s);
(gdb) print s
$1 = {length = 7, ptr = 0xf7cf7fe0 "test 10\b"}
(gdb) c
Continuing.
core.exception.AssertError at test30.d(13): test 10
[...]
Program exited with code 01.



So you can see there that the breakpoint worked and the local 
variable check while not perfect (I hear the newer gdb works 
better, but I haven't updated mine since 2010), is good enough to 
get an idea of what is going on.


Setting breakpoints by function name is harder because you need 
to know the mangled version (again maybe this works better in 
future gdbs but not on mine). For extern(C) that's easy, it is 
just the name:

(gdb) break gc_malloc
Breakpoint 1 at 0x8079058

gc_malloc is extern(C) so it knows the name.


For a D function, or worse yet, a template, getting the mangled 
name is a pain. I've never actually bothered with this before, I 
just prefer to use the file and line number.

But if you wanted to, you could pragma(msg, funcname.mangleof) to 
get it from the compiler, then:

(gdb) break _D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya
Breakpoint 1 at 0x8070870: file test30.d, line 4.
(gdb) r
Starting program: /home/me/test30
[Thread debugging using libthread_db enabled]

Breakpoint 1, 
_D6test3015__T8myformatTiZ8myformatFNaNbNexAyaxiZAya (
     _param_1=10, fmt=...) at test30.d:4
4                       return format(fmt, t);



So that works, it is just extremely awkward compared to the 
file+line number.







Another thing I do is compile every D file at once. dmd -gc 
-debug a.d everything.d here.d so.d on.d etc.d


Maybe that helps me too.

> I think we are not alone searching for such informations, so 
> can you point me somewhere in the wiki, in the documentation, 
> or similar, when there's a clear information about what version 
> of gdb to use, what it is available as functionality and what 
> not, and what compiler flags to use?

I don't really know except what works for me.

But Iain in another thread said gdb 4.6 or 4.7 works best though.