Problem Debugging with ibuclaw's GDB

[Iain Buclaw]

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.