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 Fri, Sep 14, 2001 at 07:02:24PM +0300, Eli Zaretskii wrote:

> 
> I agree with Dan here: I don't think this specific issue can be a
> valid reason for saying that GDB is ``broken'' and that ``gdb 5.1 can
> not be released'' in its current shape.

Unfortunately, this performance issue becomes "breakage" on some
platforms.  Why, MacOS X just happens to be one.  In some of our
libraries, there are a lot of these opaque struct pointers in use.
Looking up one of those variables requires gdb to sit-and-spin for
5-10 seconds, before realizing that it has no definition.  Why does
it take 5-10 seconds?  Because lookup_block_symbol was changed from
a binary search to a linear search for symbols not defined in a
given block.  After restoring the search to O-log time, the symbol
lookup returns to being unmeasurably fast.

If you're using GDB in under an IDE and you have a Locals window
open, and one of those locals is an opaque structure, whenever you
step into our out of that frame, you'll have this 5-10 second delay.
Or if you have a stack trace window open and you have some opaque
structures in that stack trace, every time that's recomputed you'll
see these huge delays.

I am hard pressed to not define this as "broken".  Particularly
when it is easy to fix, despite vague hand-waving of how this is
not correct.  

Jason


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