Re: problems with gdb

[Jim Blandy <jimb at cygnus dot com>]

> ...My problems are mostly related to how well gdb scales to handle large
> shared libraries and large numbers of shared libraries.  At last count, there
> were 111 .so files in mozilla, the largest of which is about 27 meg with
> debugging symbols.  If you don't use "set auto-solib-add 0" in your .gdbinit
> file, gdb will easily grow to over 200 meg in size when starting the
> debugger.  Someone once did some estimates and it seems to use 5 times the
> size of a .so after loading a shared library to debug.  A lot of times, gdb
> won't be able to load some of the larger .so files.  It just hangs.

I can't think of any valid reason GDB should need to use that much
memory --- it should only be building partial symtabs, which should be
small.

In any case, this is nothing special.  It's just your classic using-
too-much-memory kind of bug.  Someone needs to track down who's
chewing up all that core, and either fix the bug or improve the
design.  There's no point in pursuing general answers yet, like
mmapping debug info --- we need the concrete details first.


> A lot of times, trying to use "step" to step into a c++ method that
> happens to be part of the same class just skips as if you had used
> "next."

Yeah, I know about this one.  The problem occurs when there are
outstanding reloc to be applied to the debug info.  It's not really
related to C++, I think.  I don't understand the way relocs are
supposed to apply to shared libraries well enough to say yet how to
fix this.  I'm not even sure I understand whether they're static or
dynamic relocs.  And the last time I looked at this, I ended up being
suspicious of what objdump was telling me.  Which is the first step
towards going really insane.

I would love help here, BUT: any patch *must* be accompanied by a
detailed and coherent explanation of what's going on, why the patch is
correct, why it isn't somebody else's problem, and so on.  The fix is
probably small; it just needs to be right.


> There are other much needed features, like not being able to preload
> a .so and setting a breakpoint in the library before it loads.
> Mozilla is entirely component based and this makes debugging very,
> very difficult.  I usually break on _dl_open in glibc and wait until
> my library gets loaded before trying to set the breakpoint that I
> need.  That gets pretty bad after 27 libraries are loaded.

Right, and it's exactly the kind of bookkeeping that GDB ought to do
for you.  Mark's comments about a new GDB command seem about right to
me.

Ideally, of course, ordinary "break" would work, but you need to tell
GDB where the function lives first, so it can do error checking.