From: Daniel Berlin <dberlin@redhat.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?
Date: Sat, 28 Oct 2000 10:02:00 -0000 [thread overview]
Message-ID: <m3wves3nm1.fsf@dan2.cygnus.com> (raw)
In-Reply-To: <200010281225.OAA13546@reisser.regent.e-technik.tu-muenchen.de>
"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:
> I do not understand the need for the following change:
>
> 2000-10-12 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
>
> From Daniel Berlin <dberlin@redhat.com> :
>
> * symtab.h (SYMBOL_INIT_DEMANGLED_NAME): Initialize the symbol
> language to auto instead of unknown, so it will try to demangle
> the symbol.
>
> Dan, could you provide an example why this is needed ?
Yup.
Well, I can explain *why* it is needed.
>
> Minimal symbols are always demangled with language_auto.
> Symbol readers make sure that the proper language is used for
> SYMBOL_INIT_DEMANGLED_NAME, either via cu_language or via
> deduce_language_from_filename.
This is not true anymore.
We run into quite a few cases where the language is unknown when
symbol_init_demangled_name gets called the first time.
The problem then becomes that when, in the future, the language gets
set properly, and symbol_init_demangled_name gets called again, it
won't set the demangled name, ever, because we already tried once.
In other words, whether our demangled name gets initialized properly
or not should not depend on when we initialize it.
Before it did.
I can't see this as a valid optimization.
>
> So language_unknown should not happen normally, it looks to me like this
> change is trying to cure a symptom rather than a cause.
I spent weeks trying to track down the cause, and it appears to only
happen in certain versions of gcc. 2.95.2 comes to mind.
However, since there will be no 2.95.3, and people still need to be
debugging C++ programs, the change is needed anyway.
>
> And if we really should need this change, the comment for
> SYMBOL_INIT_DEMANGLED_NAME should be updated, currently it no longer reflects
> reality.
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
next parent reply other threads:[~2000-10-28 10:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200010281225.OAA13546@reisser.regent.e-technik.tu-muenchen.de>
2000-10-28 10:02 ` Daniel Berlin [this message]
[not found] <m31yx0oj98.fsf@dan2.cygnus.com>
2000-10-28 12:55 ` Peter.Schauer
2000-10-28 15:31 ` Daniel Berlin
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=m3wves3nm1.fsf@dan2.cygnus.com \
--to=dberlin@redhat.com \
--cc=Peter.Schauer@regent.e-technik.tu-muenchen.de \
--cc=gdb-patches@sourceware.cygnus.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