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.


  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: link
Be 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).