🚀 go-pugleaf

Lazy reading of symbols is a very neat idea, but the way it works
(at least in 3.1.2) contrary to everything the user interface
issue people have discovered. Slow response time is bad, but
what riles users even more is wildly varying response time.
Slow start-up is annoying, but one can do something else (read
news) while waiting. If individual commands are unpredictably
slow, it is much harder to do something productive while waiting.

It is not just "bt"; even more annoying is "next": I'm stepping
through a function, and everything is zipping along, and then
I call a function in a file whose symbols haven't been read yet.
Bam! I'm dead. It takes what seems like an eternity. I give up
and type ^C, thinking gdb is running wild. Etc.

I am not a naive user. I have ported gdb to a very different
platform (the V operating system - messages and no ptrace).
In spite of this, I thought the slow-ness of next was because it
was broken. I hacked our linker, debugged gas, and got gdbsyms
to work there. I thought the gdb symsegs worked great. I agree
they are too large, but that can be fixed.

Lazy reading of symbols is a great experiment. But, unless
worst-case pauses can be cut by a factor of 10, gdb is going
to be much less pleasant on large programs than it should be.

        --Per Bothner
Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301
bothner@wsl.dec.com ...!decwrl!bothner