Re: gdb and dlopen

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Oct 16, 2001 at 09:32:52PM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 16, 2001 at 06:23:39PM -0700, Kimball Thurston wrote:
> > It wasn't symbol reading inefficiency - or at least not directly. I
> > thought that at first, but I grabbed the snapshot from Oct 5th - I
> > haven't tried the latest yet, compiled it up with profiling info to
> > find where gdb is spending it's time. The majority of the time is
> > spent in child_xfer_memory - like 56% of the time (and most of that is
> > spent calling ptrace to copy bytes around) - the child_xfer_memory
> > seems to end up being called as a result of resetting breakpoints via
> > a chain of other things. I don't know why (ignorance). I've attached a
> > bzip of the profile data from the Oct 5th snapshot. Unfortunately, I
> > don't know about the internals of gdb to know what memory it's
> > transferring between processes. I tweaked on child_xfer_memory to not
> > call ptid_get_pid quite so much, but that obviously had only a
> > marginal improvement - it's all in ptrace and system calls - you can
> > see the system calls hit pretty hard from a cpuload application.
> > 
> > The plugins are very small (minus debug code info) - they should have
> > only 3 exported functions, a few static functions, and their local
> > data block has ~ 1K of data in it or so. Right now, there are about 50
> > of them.

Can you give me more information, or a testcase?  My suspicion that the
link map was responsible seems to be wrong, since I can write a dummy
application that loads 50 DSOs and debug it without any noticeable
stalls at all.

Is this application multithreaded, by chance, or at least linked to
libpthread?  The overhead in stopping and starting via the LinuxThreads
debugging package, even without multiple threads, is so ridiculous that
the times go through the roof.  I think there's something which can be
done about that.  I see a staggering amount of time spent in
svr4_current_sos, because target_read_string percolates down to
thread_db_xfer_memory and thus to thread_db_thread_alive.  We should be
able to do some intelligent caching here.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer