From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jason Molenda Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA] bug in symtab.c:lookup_block_symbol()'s search method Date: Sat, 15 Sep 2001 07:54:00 -0000 Message-id: <87ofocpks1.fsf@cgsoftware.com> References: <20010909074800.A8112@shell17.ba.best.com> <3B9D054A.4C3CC2B1@cygnus.com> <20010910113226.A23487@shell17.ba.best.com> <87zo82swwa.fsf@cgsoftware.com> <20010910130347.A5628@shell17.ba.best.com> <8766aq7nki.fsf@cgsoftware.com> <3BA219EF.3000300@cygnus.com> <9003-Fri14Sep2001190223+0300-eliz@is.elta.co.il> <20010914091241.A28921@shell17.ba.best.com> <1659-Fri14Sep2001204927+0300-eliz@is.elta.co.il> <20010915005255.A2369@shell17.ba.best.com> X-SW-Source: 2001-09/msg00190.html > > > >> 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)