From: Jim Ingham <jingham@apple.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: Search for symbol names the same way they're hashed.
Date: Wed, 02 Oct 2002 17:49:00 -0000 [thread overview]
Message-ID: <C4BE3A60-D669-11D6-BB61-00039379E320@apple.com> (raw)
In-Reply-To: <1033595444.9324.ezmlm@sources.redhat.com>
On Wednesday, October 2, 2002, at 02:50 PM,
gdb-patches-digest-help@sources.redhat.com wrote:
>> We need to make demangling-style only affect *printout* and *user
>> entered strings*, and during symbol reading, force it to auto, so it
>> always gets the right names in the symbol table in the first place.
>
> Doesn't that sort of defeat the point of letting the user set
> demangling style? It's in case something goes wrong with
> autodetection....
>
>>> The source code name of a symbol does not depend depend on the
>>> current
>>> demangling setting;
>>
>> And to enforce this, you have to make the readers *not* honor the
>> demangling style. If you just fix SYMBOL_SOURCE_NAME,
>> SYMBOL_INIT_DEMANGLED_NAME will still be only called once, and it'll
>> have the wrong demangling style when it calls cplus_demangle,
>> resulting
>> in the symbol having the wrong demangled name forevermore.
>
> Perhaps we need to decide what the point of letting users force the
> demangle style is, first.
The case where we have had to use this was because we had private C++
API's in some of the Mac OS X frameworks for 10.2 (which was compiled
with gcc 3.1) but users who didn't want to move their C++ code to 3.1
yet. When you hit the frameworks, gdb would see _Z, and assume the
mangling style was the 3.1 style. Of course, all their code was 2.95,
and they didn't in general care about the C++ stuff in frameworks
(Apple tries not to export C++ API's if it can help it). So forcing
demangling to 2.95 was useful in this case.
This should, hopefully, be just a short term problem. Very few of our
customers are still using 2.95 that we know about. But it is still
worth keeping in mind for the next year or so...
Jim
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer
next parent reply other threads:[~2002-10-03 0:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1033595444.9324.ezmlm@sources.redhat.com>
2002-10-02 17:49 ` Jim Ingham [this message]
2002-10-02 18:16 ` Daniel Jacobowitz
2002-10-02 18:25 ` Jim Ingham
2002-10-03 8:15 ` Daniel Berlin
2002-10-01 20:45 Jim Blandy
2002-10-02 10:45 ` David Carlton
2002-10-02 12:35 ` Jim Blandy
2002-10-02 12:41 ` David Carlton
2002-10-02 13:02 ` Daniel Jacobowitz
2002-10-02 13:20 ` David Carlton
2002-10-02 13:25 ` Daniel Jacobowitz
2002-10-02 13:43 ` Daniel Berlin
2002-10-02 14:03 ` Daniel Jacobowitz
2002-10-02 16:10 ` Daniel Berlin
2002-10-02 11:04 ` Daniel Jacobowitz
2002-10-02 12:10 ` David Carlton
2002-10-07 16:19 ` David Carlton
2002-10-07 16:38 ` Daniel Jacobowitz
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=C4BE3A60-D669-11D6-BB61-00039379E320@apple.com \
--to=jingham@apple.com \
--cc=gdb-patches@sources.redhat.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