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

[Daniel Berlin <dan at cgsoftware dot com>]

>
>
>
>> Anyway, I don't consider 5-10 seconds such a long time.  We still have
>> in GDB operations that take much more, and we don't consider it
>> ``broken'' because of that.
>
> It used to run in a hundredth of a second.  Now it's taking over
> three seconds, on one of our fastest machines.  When you hit the
> 'next' button in a GUI and it seizes up for four - ten seconds,
> and it didn't used to do that.  How else can it be described?  This
> behavior is not an act of god, an inevitable consequence of making
> gdb better, or an unavoidable tradeoff.  It's a mistake.
>
> The argument against this this change is that there _might_ be a
> language which has space chars at the beginning of a demangled
> string.
Not just demangled. Non-demangled names as well, since you are using
SYMBOL_SOURCE_NAME. 
Not just space chars, either
Anything strcmp_iw ignores, which is more than just space chars.

Why don't you just try to find out if Fortan, Java, Objective C, C,
and C++, as they are supported in GDB, can produce lookup_symbol's
with characters that strcmp_iw, as the first character.
In other words, why don't you just prove the patch works, before
claiming it does?
That's all i'm asking.
I couldn't achieve this, which is why i removed that code.

The fact that it slowed down C a lot for a specific case of opaque
pointers is unfortunate, but it was done in the name of correctness.
Don't pretend it's a bug.

You seem to continually miss the fact that my only objection to the
patch is that you haven't proven it to be correct. You are simply
using "vague handwaving" to say it is, such as the next sentence.
The GDB testsuite is not complete enough to be able to say something
is correct simply because it passes the testsuite.

>   lookup_block_symbol() is already very, very broken if
> that's the case. 
So?
Wouldn't be the first time.

>  The initial binary search uses a combination of
> first-letter comparisons and strcmp() -- the latter of which is
> clearly out of the question for making unmangled comparisons.

>> > 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.
>> 
>> So display the hourglass for 10 seconds and be done with that.  No one
>> will really notice, except you and me.  The world is full with good
>> software that sometimes has 10-sec delays, to say nothing of bad
>> software.
>
> I strongly disagree.  A word processor that delays for two seconds
> every time you add a new character is not acceptable.  A debugger
> that can take ten seconds to complete a "next" is not acceptable.
> If we're paging in a big shared library, there's nothing we can do
> about it.  If we're doing a linear search instead of a binary seach,
> there _is_ something we can do about it.

You only hit such bad performance in very odd cases, such as a ton of
opaque pointers.

Note that combining the solutions I later attempted avoids the problem
of having 
to show that all the languages gdb supports can't do symbol lookups
on something that starts with a character strcmp_iw ignores,
altogether.

This would be using a hash table for the block array, which we already
have a hash function ideal for (minsym_hash_iw or whatever it's
called), and the not actually searching blocks that don't contain the
symbol.

This would give you O(1) symbol lookup time, effectively (A given
symbol only searches a constant number of blocks).
This would certainly make your debugger much faster to respond.


-- 
"I wrote a few children's books...  Not on purpose.
"-Steven Wright
In-Reply-To: <20010915005255.A2369@shell17.ba.best.com> (Jason Molenda's message of "Sat, 15 Sep 2001 00:52:56 -0700")
Message-ID: <87sndopksw.fsf@cgsoftware.com>
Lines: 92
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (artichoke)