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