[Bug symtab/12707] New: physname regression: set print demangle off

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

Summary: physname regression: set print demangle off
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: symtab
AssignedTo: ***@sourceware.org
ReportedBy: ***@redhat.com
CC: ***@redhat.com
Target: x86_64-unknown-linux-gnu


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

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

Tom Tromey <tromey at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com
AssignedTo|unassigned at sourceware |tromey at redhat dot com
|dot org |

--- Comment #1 from Tom Tromey <tromey at redhat dot com> 2013-01-14 14:31:11 UTC ---
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.

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

Tom Tromey <tromey at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|tromey at redhat dot com |unassigned at sourceware
| |dot org

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2013-02-01 21:35:11 UTC ---
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.

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #3 from Tom Tromey <tromey at redhat dot com> 2013-02-08 13:35:01 UTC ---
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.

[b.r.longbons at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

Ben Longbons <b.r.longbons at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |b.r.longbons at gmail dot com

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dje at google dot com

--- Comment #4 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
*** Bug 16066 has been marked as a duplicate of this bug. ***

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #5 from dje at google dot com ---
Bug 16066 is more about the python API issue.
Let's not drop that part.

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #6 from Tom Tromey <tromey at redhat dot com> ---
I looked into my idea from comment #3 a bit.

It occurred to me that we could hack the demangler a bit to return
both the full demangled name and a pointer to the part just after the
return type.

Then we could enter both of these strings into a hash table mapping
from the demangled forms back to the mangled name.

Symbol lookup would proceed by first looking up a name in this map,
and, if found, using the mangled form as the search key.

This would let us remove the demangled hash entirely from minimal
symbols.

To get the reverse direction to be efficient we could make a second
hash table, mapping the mangled form to a canonical demangled form.


It all seems doable, maybe not even too hard. And it has some
benefits for users. However I hesitated to follow through because I
am concerned it might be taking the symbol tables in the wrong
direction.

[tromey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #7 from Tom Tromey <tromey at redhat dot com> ---
(In reply to Tom Tromey from comment #6)

Post by tromey at redhat dot com
I looked into my idea from comment #3 a bit.
Symbol lookup would proceed by first looking up a name in this map,
and, if found, using the mangled form as the search key.

For completion we can iterate over the names in the hash table.

Post by tromey at redhat dot com
This would let us remove the demangled hash entirely from minimal
symbols.
To get the reverse direction to be efficient we could make a second
hash table, mapping the mangled form to a canonical demangled form.

If we needed this direction (not clear) then we could just re-run
the demangler anyway. Or we can do like the current code, where the
name in the symtab actually points to an object in the hash.

Post by tromey at redhat dot com
It all seems doable, maybe not even too hard. And it has some
benefits for users. However I hesitated to follow through because I
am concerned it might be taking the symbol tables in the wrong
direction.

I'm not as concerned about this any more.

One wrinkle seems to be that we'd need a name canonicalizer for every
language. Of course we ought to have this anyway ... the whole idea
is really about changing the representation of the objects, not really
about changing anything fundamental. Any problems exposed are problems
already, I think.

[hgmnxact at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

hgmnxact at gmail dot com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |hgmnxact at gmail dot com

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

--- Comment #8 from dje at google dot com ---
Data point, from PR 17604.
In my monster benchmark, 12 of 13 seconds of gdb startup time (the time to get
to the prompt) is due to reading ELF symbols.
If I comment out the generation and storage of demangled copies of ELF symbols,
then startup time reduces to 2.5 seconds.
This is enough to make me seriously want to implement something along these
lines.

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12707

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
This came up again:
https://stackoverflow.com/questions/51886335/disable-name-demangling-on-gdb-startup/51896304#51896304