public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "tromey at redhat dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/12707] physname regression: set print demangle off Date: Fri, 13 Jun 2014 19:34:00 -0000 [thread overview] Message-ID: <bug-12707-4717-emZ3cVtyKv@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-12707-4717@http.sourceware.org/bugzilla/> 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) > 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. > 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. > 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. -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2014-06-13 19:34 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-27 14:58 [Bug symtab/12707] New: " jan.kratochvil at redhat dot com 2013-01-14 14:31 ` [Bug symtab/12707] " tromey at redhat dot com 2013-01-18 14:28 ` tromey at redhat dot com 2013-02-01 21:35 ` tromey at redhat dot com 2013-02-08 13:35 ` tromey at redhat dot com 2013-07-30 0:10 ` b.r.longbons at gmail dot com 2013-10-19 18:38 ` jan.kratochvil at redhat dot com 2013-10-19 19:40 ` dje at google dot com 2013-11-21 19:03 ` tromey at redhat dot com 2014-06-13 19:34 ` tromey at redhat dot com [this message] 2014-10-10 11:09 ` hgmnxact at gmail dot com 2014-11-15 0:07 ` dje at google dot com 2020-03-25 19:24 ` tromey at sourceware dot org 2020-04-24 21:36 ` cvs-commit at gcc dot gnu.org 2020-04-24 21:39 ` tromey at sourceware dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12707-4717-emZ3cVtyKv@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).