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

Eli Zaretskii eliz@is.elta.co.il
Fri Sep 14 11:57:00 GMT 2001


> Date: Fri, 14 Sep 2001 14:00:51 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Even if the performance hit is significant, I fail to understand how
> > can someone say the entire program is broken, or that it cannot be
> > released.  Can we please get things back into their proportion?
> 
> This much I can mostly agree with, but...
> 
> > 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.
> 
> Maybe you don't.  I'm sure I'm not the only one who would like to start
> eliminating them.

You are not the only one: I also would like them to be eliminated, as
I'm sure is Dan and everyone else on this list.

The issue is not whether to eliminate them, but whether their presence
makes GDB ``broken'' and unsuitable for a release, and whether it
justifies the unfortunate wording seen in this thread that made Dan
feel he is unwanted here.

I think the answer to the last two issues is a qualified NO.

> A lot of operations take frustratingly long that shouldn't.

Yes, we have quite a few operations in GDB that are slow, some of them
painfully slow.  But please do not attack people who wrote the slow
code.  Please let's assume that we all write the best code we can come
up with, and even if someone errs (and we all do), that someone
doesn't deserve to be bashed.

Dan, in particular, has a long history of eliminating slow code from
GDB, and I think he doesn't deserve to be accused in the opposite.

I'm sorry to sound as if I were preaching, but it disturbs me deeply
to see technical discussions to turn into personal flamewar.

> For instance, Jason is probably testing on a machine capable of
> displaying a GUI IDE and running MacOS X.  That means a PowerPC,
> presumably, and at least in the 300MHz-500MHz range.  I do much of my
> native GDB testing on a 50MHz MIPS R5432 board, which is probably on
> the order of thirty or forty times slower.  His ten second delays
> become my five minute coffee breaks.

Every modern program will be slow in a 50MHz machine.  For example,
Emacs will not be able to keep up with the keyboard auto-repeat rate
and scroll the display if you press and hold C-v.

Again, I'm not against eliminating delays, if they keep the code
correct.

> Not if every Step instruction takes ten seconds!  That makes debugging
> practically infeasible.

I disagree.  Many of my colleagues on my day-time job use debuggers
(not GDB) which does take on the order of 5 seconds to step on a fast
machine (a 3-CPU 250MHz SGI box), and none of them thinks it's
infeasible.

Again, please don't misinterpret me: I'm all for eliminating delays.
But taking things out of proportion, and then attacking people based
on those out-of-proportion impressions is something that I cannot say
I care about.



More information about the Gdb-patches mailing list