www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Problem Debugging with ibuclaw's GDB

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
I have successfully built and installed ibuclaw's gdb branch on 
github on my Ubuntu 13.10 x86_64 with its default compiler gcc 
4.8.1.

I had to remove the file ld from the bin sub directory otherwise 
dmd complains about a sysroot thing in link phase.

When I then compile my test program and run through gdb I have 
problems.

I can do `break main`

but when I do `next` I get the following output

   Single stepping until exit from function main,
   which has no line number information.
   0x00007ffff760ede5 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6

Isn't ibuclaw's gdb supposed to work here?

My test program was compiled as

dmd -debug -g -gs -unittest -wi -main  ~/Work/justd/t_msgpack.d 
/home/per/Work/justd/dbg.d /home/per/Work/justd/msgpack.d 
-of/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/t_msgpack

without any warnings nor errors.

Further when I do `b ` followed by tab, most of the symbols in 
the completion list are not demangled. For example

...
D main
Exception.classinfo$
Exception.init$
Exception.vtbl$
Object.Monitor.interface$
Object.classinfo$
Object.init$
Object.vtbl$
TypeInfo.classinfo$
TypeInfo.init$
TypeInfo.vtbl$
TypeInfo_AAya.init$
TypeInfo_APS3std8datetime13PosixTimeZone14TransitionType.init$
TypeInfo_APxS2rt3aaA5Entry.init$
TypeInfo_APxS6object10ModuleInfo.init$
TypeInfo_APyS3std8datetime13PosixTimeZone6TTInfo.init$
TypeInfo_AS2rt15deh_win64_posix9FuncTable.init$
TypeInfo_AS3std3uni17CodepointInterval.init$
TypeInfo_AS3std4file15DirIteratorImpl9DirHandle.init$
TypeInfo_AS3std4file8DirEntry.init$
TypeInfo_AS3std8datetime13PosixTimeZone10LeapSecond.init$
TypeInfo_AS3std8datetime13PosixTimeZone10TempTTInfo.init$
TypeInfo_AS3std8datetime13PosixTimeZone10Transition.init$
TypeInfo_AS3std8datetime13PosixTimeZone14TempTransition.init$
...
Jan 09 2014
parent reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Thursday, 9 January 2014 at 17:35:56 UTC, Nordlöw wrote:

 I have successfully built and installed ibuclaw's gdb branch on 
 github on my Ubuntu 13.10 x86_64 with its default compiler gcc 
 4.8.1.

 I had to remove the file ld from the bin sub directory 
 otherwise dmd complains about a sysroot thing in link phase.

 When I then compile my test program and run through gdb I have 
 problems.

 I can do `break main`

 but when I do `next` I get the following output

   Single stepping until exit from function main,
   which has no line number information.
   0x00007ffff760ede5 in __libc_start_main () from 
 /lib/x86_64-linux-gnu/libc.so.6

 Isn't ibuclaw's gdb supposed to work here?



That is working as per intended.  When you `break main`, you are 
setting a breakpoint at the C main function.

In the past you would have to type in either of the following to 
set a breakpoint at D's main.

   break _Dmain
   break 'D main'

Now with my patches, you can simply use 'start', and gdb will 
stop at the correct place for you.

See: https://sourceware.org/gdb/onlinedocs/gdb/Starting.html

"""
start
     The name of the main procedure can vary from language to 
language. With C or C++, the main procedure name is always main, 
but other languages such as Ada do not require a specific name 
for their main procedure. The debugger provides a convenient way 
to start the execution of the program and to stop at the 
beginning of the main procedure, depending on the language used.
"""


 My test program was compiled as

 dmd -debug -g -gs -unittest -wi -main  ~/Work/justd/t_msgpack.d 
 /home/per/Work/justd/dbg.d /home/per/Work/justd/msgpack.d 
 -of/home/per/.emacs.d/auto-builds/dmd/Debug-Boundscheck-Unittest/home/per/Work/justd/t_msgpack

 without any warnings nor errors.

 Further when I do `b ` followed by tab, most of the symbols in 
 the completion list are not demangled. For example

 ...
 D main
 Exception.classinfo$
 Exception.init$
 Exception.vtbl$
 Object.Monitor.interface$
 Object.classinfo$
 Object.init$
 Object.vtbl$
 TypeInfo.classinfo$
 TypeInfo.init$
 TypeInfo.vtbl$
 TypeInfo_AAya.init$
 TypeInfo_APS3std8datetime13PosixTimeZone14TransitionType.init$
 TypeInfo_APxS2rt3aaA5Entry.init$
 TypeInfo_APxS6object10ModuleInfo.init$
 TypeInfo_APyS3std8datetime13PosixTimeZone6TTInfo.init$
 TypeInfo_AS2rt15deh_win64_posix9FuncTable.init$
 TypeInfo_AS3std3uni17CodepointInterval.init$
 TypeInfo_AS3std4file15DirIteratorImpl9DirHandle.init$
 TypeInfo_AS3std4file8DirEntry.init$
 TypeInfo_AS3std8datetime13PosixTimeZone10LeapSecond.init$
 TypeInfo_AS3std8datetime13PosixTimeZone10TempTTInfo.init$
 TypeInfo_AS3std8datetime13PosixTimeZone10Transition.init$
 TypeInfo_AS3std8datetime13PosixTimeZone14TempTransition.init$
 ...


Unfortunately they are demangled.  Those TypeInfo symbols are 
just a quirk of D's mangling scheme that doesn't follow the 
documented convention: (http://dlang.org/abi.html)

For instance, lets look at the mangled version of one of those 
symbols:

_D26TypeInfo_APxS2rt3aaA5Entry6__initZ


How is this parsed?  Well, this is the grammar used in GDB (based 
off the D ABI page, and simplified a little for ease of reading):

MangledName:
     _D QualifiedName Type

QualifiedName:
     SymbolName
     SymbolName QualifiedName

SymbolName:
     Numbers Name

Name:
     Alpha
     Alpha AlphaNumerics

Alpha:
     _
     [a-zA-Z]

Number:
     [0-9]

Numbers:
     Number
     Number Numbers

AlphaNumeric:
     Alpha
     Number

AlphaNumerics:
     AlphaNumeric
     AlphaNumeric AlphaNumerics



When parsing/evaluating the symbol 
`_D26TypeInfo_APxS2rt3aaA5Entry6__initZ` we get through the 
following path:

_D(_D) Numbers(26) Alpha(T) 
AlphaNumerics(ypeInfo_APxS2rt3aaA5Entry) Numbers(6) Alpha(_) 
AlphaNumerics(_init) Type(Z)

-> _D(_D) Numbers(26) Name(TypeInfo_APxS2rt3aaA5Entry) Numbers(6) 
Name(__init) Type(Z)

-> _D(_D) SymbolName(26TypeInfo_APxS2rt3aaA5Entry) 
SymbolName(6__init) Type(Z)

-> _D(_D) QualifiedName(26TypeInfo_APxS2rt3aaA5Entry6__init) 
Type(Z)

-> MangledName(_D26TypeInfo_APxS2rt3aaA5Entry6__initZ)


The result?

(gdb) set language d
(gdb) maintenance demangle _D26TypeInfo_APxS2rt3aaA5Entry6__initZ
TypeInfo_APxS2rt3aaA5Entry.init$


It's perfectly valid, if somewhat unfortunate that D sets the 
SymbolName length to 26, meaning that the entire mangled name is 
eaten up (not demangled).  Unfortunately only the compiler itself 
can fix this discrepancy, as it seems to be generating a mangled 
symbol that is outside of the documented grammar.

Regards
Iain.
Jan 09 2014
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 Now with my patches, you can simply use 'start', and gdb will 
 stop at the correct place for you.


Wonderful!

BTW: Why can't I do `b main`, `r`, `n` like I'm used to in C, 
then?

What if I want to set a breakpoint somewhere deep down in the 
call stack and execute to that. Do I always first have to do 
`start`and then `continue` to get to my breakpoint.

There also seems to be a bug in the symbol completion

   b std.std TAB complete

but

   b std.stdio TAB

shows nothing and

   b std.stdio. TAB

shows incorrect results.

Anyway, superthanks! My D debugging productivity just rose with a 
magnitude!
Jan 09 2014
next sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
Hardly any symbol is presented correctly when doing `print 
SYMBOL` in GDB with regards to name demangling and their value. 
Is this the current state of ibuclaws GDB or have I missed 
something?

/Per
Jan 09 2014
parent "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Thursday, 9 January 2014 at 19:33:54 UTC, Nordlöw wrote:

 Hardly any symbol is presented correctly when doing `print 
 SYMBOL` in GDB with regards to name demangling and their value. 
 Is this the current state of ibuclaws GDB or have I missed 
 something?

 /Per


I've only tested this with GDC.  DMD may represent symbols 
incorrectly in debug, and there's nothing GDB can do about it.
Jan 10 2014
prev sibling next sibling parent "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Thursday, 9 January 2014 at 18:53:46 UTC, Nordlöw wrote:

 Now with my patches, you can simply use 'start', and gdb will 
 stop at the correct place for you.


 Wonderful!

 BTW: Why can't I do `b main`, `r`, `n` like I'm used to in C, 
 then?


As I said, `b main` works.  It sets a breakpoint at the C main 
function.



 What if I want to set a breakpoint somewhere deep down in the 
 call stack and execute to that. Do I always first have to do 
 `start`and then `continue` to get to my breakpoint.


No, just set your breakpoint at the location you want and then 
`run`



 There also seems to be a bug in the symbol completion

   b std.std TAB complete

 but

   b std.stdio TAB

 shows nothing and

   b std.stdio. TAB

 shows incorrect results.


For the time being I'd suggest putting quotes around qualified 
names.
Eg:

     b 'std.std TAB


You have to do it this way because a D-specific expression parser 
hasn't been written yet, and the one used for C/C++ doesn't 
understand '.' to be a qualified identifier separator. This is 
intended to be fixed in the near future.
Jan 10 2014
prev sibling parent reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Thursday, 9 January 2014 at 18:53:46 UTC, Nordlöw wrote:

 Anyway, superthanks! My D debugging productivity just rose with 
 a magnitude!


Not much has been done yet.  Though I do suggest using cgdb - 
http://cgdb.github.io if you want a boost in productivity. =)
Jan 10 2014
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Friday, 10 January 2014 at 10:10:02 UTC, Iain Buclaw wrote:

 On Thursday, 9 January 2014 at 18:53:46 UTC, Nordlöw wrote:

 Anyway, superthanks! My D debugging productivity just rose 
 with a magnitude!


 Not much has been done yet.  Though I do suggest using cgdb - 
 http://cgdb.github.io if you want a boost in productivity. =)


Does cgdb provide any enhancements compared to running GDB 
through Emacs' GUD/GDB (which I prefer as I'm an Emacs guy).

/Per
Jan 10 2014
parent reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
On Friday, 10 January 2014 at 13:53:27 UTC, Nordlöw wrote:

 On Friday, 10 January 2014 at 10:10:02 UTC, Iain Buclaw wrote:

 On Thursday, 9 January 2014 at 18:53:46 UTC, Nordlöw wrote:

 Anyway, superthanks! My D debugging productivity just rose 
 with a magnitude!


 Not much has been done yet.  Though I do suggest using cgdb - 
 http://cgdb.github.io if you want a boost in productivity. =)


 Does cgdb provide any enhancements compared to running GDB 
 through Emacs' GUD/GDB (which I prefer as I'm an Emacs guy).

 /Per


I guess not.  cgdb uses a vi-inspired interface. ;-)
Jan 10 2014
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Friday, 10 January 2014 at 19:04:34 UTC, Iain Buclaw wrote:

 On Friday, 10 January 2014 at 13:53:27 UTC, Nordlöw wrote:

 On Friday, 10 January 2014 at 10:10:02 UTC, Iain Buclaw wrote:

 On Thursday, 9 January 2014 at 18:53:46 UTC, Nordlöw wrote:

 Anyway, superthanks! My D debugging productivity just rose 
 with a magnitude!


 Not much has been done yet.  Though I do suggest using cgdb - 
 http://cgdb.github.io if you want a boost in productivity. =)


 Does cgdb provide any enhancements compared to running GDB 
 through Emacs' GUD/GDB (which I prefer as I'm an Emacs guy).

 /Per


 I guess not.  cgdb uses a vi-inspired interface. ;-)


That's what I thought, traitors! ;)

Thx.
Jan 10 2014