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

[Daniel Berlin <dan at cgsoftware dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:

>>> IMNSHO gdb 5.1 can not be released with the symbol binary search
>>> lookup broken as it has been for the last year.
>> Broken?
>> You mean slower.
>> It works *correctly*, just not as *efficiently* as it could.
>> Big difference.
>
> gdb is measured against many criteria, one is performance.  if gdb's
> performance drops, gdb has regressed.  some would describe it as
> broken.
By that measure, gdb has been broken for a *long* time, well before my
patch.

>
> in some some situtations - replacing a macro by a function say - such
> a regression is considered acceptable.  in other cases - such as an
> algorithm change that is ment to improve performance - it is not.
Pardone?
As you will note, my patch improved correctness in corner cases, at
the expense of some performance.
Jason's patch will remove that correctness, on the assumption that
these corner cases never occur, which nobody has answered definitively
either way for all the languages GDB supports.
If someone would have told me that other languages besides C and C++
will never cause symbol lookups to start with something strcmp_iw
ignores, i would have not removed that portion of the code.  There
was no obvious correctness to the code that existed before, in fact,
it was obviously broken in cases. The question was whether these cases
can occur or not. 
Removing the code was not unintentional.  Nobody ever answered the
emails, so i did the safe thing.
I've been yelled at before for valuing performance over
correctness. So I value correctness over performance, and get yelled
at again.
Is it any wonder I don't participate in GDB development anymore?
>
> andrew
>

-- 
"If toast always lands butter-side down, and cats always land on
their feet, what happen if you strap toast on the back of a cat
and drop it?
"-Steven Wright