RFA: Search for symbol names the same way they're hashed.

[Daniel Berlin]

On Wednesday, October 2, 2002, at 09:24  PM, Jim Ingham wrote:

> Daniel,
>
> On Wednesday, October 2, 2002, at 06:16  PM, Daniel Jacobowitz wrote:
>
>> On Wed, Oct 02, 2002 at 05:48:01PM -0700, Jim Ingham wrote:
>>>
>>> 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...
>>
>> Time to unconfuse one issue:
>>
>> Jim, are you sure that you are talking about _demangling_ style?  It 
>> is
>> orthogonal to 'set cp-abi'.  I'm talking about 'set demangle-style'
>> here.  I assume in a mixed v2/v3 environment you'd want 'auto' anyway.
>>
>
> Oh, sorry, my mistake...  But you don't want "auto" in a mixed 
> environment, because auto chooses v3 when it sees it.  For the folks 
> using v2, the v3 bits are all stuff they don't care at all about.  So 
> you have to force it to v2.  We did all this already, however, IIRC...
>
No, auto doesn't *switch* to v3 mode, when it sees a v3, it just uses 
the v3 demangler for that string.
If you next hand it a v2 string, it should demangle it properly as well.
Otherwise, something is broken.

I just tried it with C++filt, to make sure, and it does work:
bash-2.05a$ c++filt
_a__3bob [This is a v2 mangled name]
bob::a(void)
__ZN3bob1aEv [This is a v3 mangled name]
bob::a()

--Dan