Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 09, 2014 Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
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$ ... |
January 09, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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. |
January 09, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | > 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!
|
January 09, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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 |
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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. |
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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.
|
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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. =) |
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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
|
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nordlöw | 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. ;-)
|
January 10, 2014 Re: Problem Debugging with ibuclaw's GDB | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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.
|
Copyright © 1999-2021 by the D Language Foundation