problems with gdb

[Chris Blizzard <blizzard at mozilla dot org>]

Hi, folks.  I've been talking about some problems that I've been suffering
through with gdb and mozilla which people on this mailing list may or may not
be aware of.  Jason Molenda suggested that I start flushing these out in the
open to get some feedback on them.

I'm interested in getting my hands dirty and try to get these problems fixed. 
I'm not a debugger hacker though so I might end up asking some silly
questions.  :)

Here's the blurb, slightly edited for content.

...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.

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."  That means
that any time you want to step into a method you have to set a temporary
breakpoint by name on the method and then allow the breakpoint to get you into
that method.  Doing that to step into a dozen or so classes gets a little
tedious.  This is hard to reproduce and I'm trying to build a test case.

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.

There are also various problems with threads.  A lot of times gdb won't exit
after the last thread exits because it keeps trying to kill a process which
doesn't exist any more.

We've got a deubugging FAQ that tries to show ways to work around deficencies
in the deubugger:

http://www.mozilla.org/unix/debugging-faq.html

There are a lot of people who work at Netscape who would be using Linux as
their primary platform if, and I'm quoting here, "using gdb wasn't like
scratching your own eyes out."  This is one of the reasons why Mozilla is so
much slower on Linux than it is on windows.  People waste so much time
debugging on it that they just give up.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I'm not into working out. My philosophy: No pain, no pain.
------------