This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method



On Tuesday, September 18, 2001, at 02:11 AM, Jason Molenda wrote:

> On Tue, Sep 18, 2001 at 01:56:36AM -0400, Andrew Cagney wrote:
>
>> The suggested criteria for committing something to the 5.1 branch are:
>>
>> 	o	does it build (and if not did it build in 5.0/4.18)
>>
>> 	o	does ``break main; run'' work
>
> If the bar is that high for patches on the release branch, then
> this change does not meet it.  We'll still need to address this on
> the trunk.
Yes, of course.
>
>> Jason, you've indicate that this seriously hurts Apple's GDB branch.
>
> Fear not, it's already patched in the Apple GDB branch. :-)
>
> My concern is for (a) environments where pointers to undefined
> structures are used, and (b) lookups of undefined symbols.  Obviously
> it's not a great travisty if (b) is slow, but (a) will hit anyone
> who has libraries that try to hide the implementation from the
> interface in the same way that the Appple Carbon libraries do.

This doesn't quite happen as often as you think.
Undefined symbol lookups have always been the absolute worst case, even 
ignoring the lookup_block_symbol slowness, since it can force readin of 
all psymtabs, and require us to search minsyms.


>
> I probably won't have time until next weekend, but I'll be sending
> modified versions of the profiling and symtab patches to incorporate
> many of the suggestions on the list.
>
I hope you take a look at the patch I sent you, as it's a good deal 
faster than the binary search.

> Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]