Re: Slow handling of C++ symbol names

[Will Cohen <wcohen@redhat.com>]

Andrew Cagney wrote:
>> But without looking at the data we've no idea how substantial any
>>
>>> particular part really is.  For instance, when analysing the bcache 
>>> found that when debugging a C program every entry is 28 bytes in size!
>>>
>>> 'foo(int)' can be broken down into "foo" "(int)" the latter only 
>>> being demanged and stored on-demand.
>>
>>
>>
>> "They" tell me that the demangler did not support doing this.  But it
>> may soon.
>>
>> Will, you may want to test a CVS snapshot from today or later.  The
>> demangler for GNU v3 was replaced last night; the new one appears to be
>> about twice as efficient.
> 
> 
> FYI, Will got hold of an RPM based on 20031117 and I believe the 
> performance numbers came back the same as 6.0 :-(  That would make it 
> post your changes but pre the new demangler.
> 
> I guess we get to restart the analysis :-(
> 
> Andrew


I tried a very recent snapshot of gdb and libiberty (used the uberbaum 
checkout the to get pieces 2003/11/25). The uberbaum appears to be 
broken and doesn't build to completion, but it does build gdb 
executable. However, the new cp-demangler.c gets a segfault error when 
the gdb executable is loading the monotone executable. I have filed a 
bugzilla entry, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13206 . It 
looks like there is some more work required.

The problem is definitely related to the processing of the debugging 
information. The gdb executable loads the stripped version of the 
monoexecutable without problem.

-Will