From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Demangle function names when disassembling
Date: Fri, 24 Jul 2020 14:18:47 -0600 [thread overview]
Message-ID: <87eep0bra0.fsf@tromey.com> (raw)
In-Reply-To: <20200724090819.GN853475@embecosm.com> (Andrew Burgess's message of "Fri, 24 Jul 2020 10:08:19 +0100")
Andrew> It turns out that the bug that originally caused GDB to display
Andrew> demangled names only applied for some languages, Ada, didn't have
Andrew> this issue, and so has always displayed the mangled names.
Ada is special here ... but I am not sure there's a very good reason for
it. I've been meaning for a while to see if this difference can be
removed. Mostly, I think this amounts to demangling Ada names during
symbol reading.
Andrew> So my initial thought was, lets make 'set print asm-demangle' be on by
Andrew> default. Then we've still fixed the bug in GDB (about storing the
Andrew> mangled vs demangled symbols), but the behaviour of GDB doesn't
Andrew> actually change (vs 9.x release).
It seems like we could still do this.
Andrew> First, and maybe the smallest problem, boolean variables have the
Andrew> "feature" that a user can just type 'set print asm-demangle', which is
Andrew> equivalent to 'set print asm-demangle on'. However, this doesn't work
Andrew> for auto-booleans, in that case you must type 'set print asm-demangle
Andrew> on'.
I think we could just safely ignore this. I wasn't even aware of this
feature; and anyway it's easy to work around; and finally nobody has
added a asm-demangle setting in 10 years or so due to the bug.
Andrew> If I flip the default for 'asm-demangle' on the grounds that I don't
Andrew> think we should suddenly change GDB's behaviour then this would only
Andrew> be for C++, for Ada I would be suddenly changing the default.
I think this is probably fine as well. I think it makes sense for the
option to do what the documentation says it will do. Users, if they
notice this, can change the setting.
Yet another option would be to change my patch up-thread to use
"demangle" for the header rather than "asm-demangle". I tend to think
that would be more confusing, but I figured I'd mention it.
I looked into the history of "asm-demangle", but it seems to predate the
sourceware import.
Andrew> [...] in some places 'asm_demangle' is completely
Andrew> independent, and in other places 'asm_demangle' actually overrides
Andrew> 'demangle' rather than deferring to it.
Bleah. Can / should we fix this.
There's also "set demangle-style", which is both obsolete and inherently
broken. It should be removed.
Andrew> + if (asm_demangle == AUTO_BOOLEAN_AUTO)
Andrew> + fprintf_filtered (file,
Andrew> + _("Demangling of C++/ObjC names in disassembly "
We should probably use this opportunity to drop the C++/ObjC text, since
this applies to any language with mangling.
Tom
next prev parent reply other threads:[~2020-07-24 20:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 16:10 Tom Tromey
2020-07-23 16:22 ` Andrew Burgess
2020-07-24 9:08 ` Andrew Burgess
2020-07-24 20:18 ` Tom Tromey [this message]
2020-07-28 17:47 ` Tom Tromey
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=87eep0bra0.fsf@tromey.com \
--to=tom@tromey.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@adacore.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