This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method
- To: Jason Molenda <jason-swarelist at molenda dot com>
- Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Tue, 18 Sep 2001 09:21:17 -0400
- Cc: Andrew Cagney <ac131313 at cygnus dot com>, gdb-patches at sources dot redhat dot com
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