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$
...

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.

> 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!

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

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.

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.

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. =)

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

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. ;-)

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.