Sources Bugzilla – Bug 12707
physname regression: set print demangle off
Last modified: 2013-02-08 13:35:01 UTC
void f () { } int main () { f (); } gcc -g (gdb) break f Breakpoint 1 at 0x4004d8: file .../demangle.C, line 1. (gdb) run pre-physname: (gdb) set print demangle off (gdb) frame #0 _Z1fv () at .../demangle.C:1 ^^^^^^^^ post-physname: (gdb) set print demangle off (gdb) frame #0 f () at .../demangle.C:1 ^^^^ there is a regression by the patch (not verified this specific commit has regressed it but I guess so): 42284fdf9d8cdb20c8e833bdbdb2b56977fea525 http://sourceware.org/ml/gdb-cvs/2010-03/msg00082.html dwarf2_physname patchset: [RFA] dwarf2_physname FINAL http://sourceware.org/ml/gdb-patches/2010-03/msg00220.html
I looked into this and I'm working on a patch. The first problem is that the mangled name is no longer stored. This is pretty easy to fix but then there is some unrelated fallout.
The thread starts here: http://sourceware.org/ml/gdb-patches/2013-01/msg00287.html Jan is probably correct that we should store 3 forms for the template symbols in question: http://sourceware.org/ml/gdb-patches/2013-01/msg00381.html A more complicated approach is possible, based on checking the name-without-return-type, and then filtering the results. However this seems more difficult to get right. A third idea would be to introduce a kind of alias symbol that points to the "canonical" one. This might help avoid some data structures issues -- e.g., minsyms assume right now there can only be 2 names for a symbol, as minsyms only have 2 "next" pointers.
Another idea occurred to me - always store just the mangled form in the symbol, and have a table mapping demangled form(s) to the mangled form. Then when printing a symbol, demangle on demand, if needed.