Bug 3387 – gdb: symbols in the backtrace are not demangled

In DMD 1.046 or older, the backtrace were broken but the symbol were demangled (using the D GDB patch at least). Starting at version 1.047, the symbols are not demangled anymore in GDB. Same test program as bug 136: -------- void main() { static int i = 0; while (i++ < 10) main(); *(cast(int *)0) = 0; } -------- DMD evolution: 1.046 ===== -------------------- GNU gdb (GDB) 7.0.50.20090919 [...] Reading symbols from /home/luca/tesis/dmd-1.049/dmd/linux/bug136...done. (gdb) bt No stack. (gdb) run Starting program: /home/luca/tesis/dmd-1.049/dmd/linux/bug136 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08049b12 in D main () Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 0x08049b12 in D main () #1 0xbffff4d4 in ?? () #2 0xbffff4a0 in ?? () #3 0x08049b0c in D main () Backtrace stopped: previous frame inner to this frame (corrupt stack?) -------------------- 1.047 ===== -------------------- GNU gdb (GDB) 7.0.50.20090919 [...] Reading symbols from /home/luca/tesis/dmd-1.049/dmd/linux/bug136...done. (gdb) run Starting program: /home/luca/tesis/dmd-1.049/dmd/linux/bug136 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08049b12 in _Dmain () at bin/bug136.d:6 6 *(cast(int *)0) = 0; Current language: auto The current source language is "auto; currently d". (gdb) bt #0 0x08049b12 in _Dmain () at bin/bug136.d:6 #1 0xbffff4d4 in ?? () #2 0xbffff4a0 in ?? () #3 0x08049b0c in _Dmain () at bin/bug136.d:5 Backtrace stopped: previous frame inner to this frame (corrupt stack?) -------------------- 1.049 ===== -------------------- -------------------- GNU gdb (GDB) 7.0.50.20090919 [...] Reading symbols from /home/luca/tesis/dmd-1.049/dmd/linux/bug136...done. (gdb) run Starting program: /home/luca/tesis/dmd-1.049/dmd/linux/bug136 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08049b12 in _Dmain () at bin/bug136.d:6 6 *(cast(int *)0) = 0; Current language: auto The current source language is "auto; currently d". (gdb) bt #0 0x08049b12 in _Dmain () at bin/bug136.d:6 #1 0x08049b0c in _Dmain () at bin/bug136.d:5 #2 0x08049b0c in _Dmain () at bin/bug136.d:5 #3 0x08049b0c in _Dmain () at bin/bug136.d:5 #4 0x08049b0c in _Dmain () at bin/bug136.d:5 #5 0x08049b0c in _Dmain () at bin/bug136.d:5 #6 0x08049b0c in _Dmain () at bin/bug136.d:5 #7 0x08049b0c in _Dmain () at bin/bug136.d:5 #8 0x08049b0c in _Dmain () at bin/bug136.d:5 #9 0x08049b0c in _Dmain () at bin/bug136.d:5 #10 0x08049b0c in _Dmain () at bin/bug136.d:5 #11 0x08057599 in main () -------------------- The backtrace looks nice in DMD 1.049 but the symbols can't be demangled by GDB.

BTW DMD 2.034 works fine: ---------- (gdb) bt #0 0x080490cb in D main () #1 0x080490c5 in D main () #2 0x080490c5 in D main () #3 0x080490c5 in D main () #4 0x080490c5 in D main () #5 0x080490c5 in D main () #6 0x080490c5 in D main () #7 0x080490c5 in D main () #8 0x080490c5 in D main () #9 0x080490c5 in D main () #10 0x080490c5 in D main () #11 0x080493b4 in rt.dmain2.main() () #12 0x080491bd in rt.dmain2.main() () #13 0x080493f6 in rt.dmain2.main() () #14 0x080491bd in rt.dmain2.main() () #15 0x08049168 in main () ------------

It doesn't look like a regression after all, it seems to depend on whatever -g or -gc is used. With -g I get the properly demangled names, but with -gc I don't. The problem is, -g is broken with GDB, so I can't use -g. It would be a problem to have -gc producing the necessary debug info to get properly demangled names? Sorry for the noise.

I've removed the wrong-code keyword, and closing this bug, as it isn't a dmd issue. The code generated is correct, as -gc means D should pretend to be C... Which means symbol names have to be mangled, as otherwise they are not valid C symbols. It also means gdb won't demangle them, as it detects C and not D. The correct solution for this bug is to add support for the D extensions to gdb, there's nothing dmd can do about this without adding another debugging mode, something I think is best avoided.