From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [RFA 3/3] Move logic out of symbol_find_demangled_name
Date: Fri, 17 Jun 2016 12:25:00 -0000 [thread overview]
Message-ID: <9a9f6440-f369-d729-71ff-ea961aac3100@redhat.com> (raw)
In-Reply-To: <874m8sp6dh.fsf@tromey.com>
On 06/17/2016 09:27 AM, Tom Tromey wrote:
> Pedro> Actually, AFAICS, the new code does the same thing, because the
> Pedro> C++ version and the Rust version are exactly the same.
>
> Yeah, I forgot about that when replying.
>
> Pedro> IIUC, from Rust 1.9 onward, Rust uses C++ mangling, so basically
> Pedro> there's no way to tell a C++ symbol from a Rust symbol from the
> Pedro> mangled name alone. Correct?
>
> Yes. Java is in this situation as well. However I think it only
> matters for minimal symbols as symbols coming from DWARF typically have
> a language.
OK. I still think we should have a comment clarifying this.
The new comment mentions that we'll attempt demangling in the
order the constants are defined, but doesn't explain the
dependencies that led to the particular order you chose.
I think we could tweak the comment at the top of enum language
to something around this:
Note that there's ambiguity between the mangling schemes of some of
these languages, so some symbols could be successfully demangled by
several languages. For that reason, the constants here are sorted
in the order we'll attempt demangling them. For example: Java and
Rust use C++ mangling, so must come after C++; Ada must come last
(see ada_sniff_from_mangled_name).
>
> I think it would be better if Rust changed its mangling, but AFAIK
> nobody has seriously proposed this there yet.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-06-17 12:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-04 14:49 [RFA 0/3] minor language cleanups Tom Tromey
2016-06-04 14:49 ` [RFA 3/3] Move logic out of symbol_find_demangled_name Tom Tromey
2016-06-06 14:15 ` Yao Qi
2016-06-07 11:41 ` Tom Tromey
2016-06-07 14:27 ` Pedro Alves
2016-06-07 15:12 ` Tom Tromey
2016-06-13 13:35 ` Pedro Alves
2016-06-17 8:28 ` Tom Tromey
2016-06-17 12:25 ` Pedro Alves [this message]
2016-06-17 12:36 ` Tom Tromey
2016-06-17 13:50 ` Pedro Alves
2016-06-24 3:15 ` Tom Tromey
2016-06-07 14:03 ` Pedro Alves
2016-06-08 2:14 ` Tom Tromey
2016-06-08 4:03 ` Tom Tromey
2016-06-13 13:35 ` Pedro Alves
2016-06-17 8:41 ` Tom Tromey
2016-06-17 12:28 ` Pedro Alves
2016-06-04 14:49 ` [RFA 2/3] Move filename extensions into language_defn Tom Tromey
2016-06-06 13:23 ` Yao Qi
2016-06-06 21:04 ` Tom Tromey
2016-06-07 15:51 ` Yao Qi
2016-06-04 14:49 ` [RFA 1/3] Use VEC for filename_language_table Tom Tromey
2016-06-06 13:06 ` Yao Qi
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=9a9f6440-f369-d729-71ff-ea961aac3100@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.com \
--cc=tom@tromey.com \
/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