Re: gdb and dlopen

[Kimball Thurston <kimball at sgrail dot com>]

At Tue, 16 Oct 2001 16:15:25 -0400,
Daniel Jacobowitz wrote:
> 
> On Tue, Oct 16, 2001 at 01:11:39PM -0700, Kimball Thurston wrote:
> > Hey all,
> > 
> >    In our application, we've got a plugin architecture that, under
> > unix, we open using dlopen et al. When trying to debug using gdb, the
> > process of calling dlopen seems to take an extraordinary amount of
> > time, as it looks like gdb is using ptrace to copy a bunch of the
> > debug process's memory at each dlopen into itself. Is there a way to
> > delay this behavior, or disable it all together, or fix it? I couldn't
> > determine exactly how gdb uses the memory it copies in. All I know is
> > it makes using gdb nearly impossible when you have to wait 10 minutes
> > for the program to start up...
> 
> You might want to look at some of the options under 'set debug' to see
> what it's doing.  It's possible that it's just symbol reading
> inefficiency biting you; how big are these DSOs?  How many are there?
> 

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.

What is the purpose child_xfer_memory is called for? Maybe I can go
through and change that to a delayed load-on-access type scenario or
something?

thanks,
Kimball

gdb_prof_data.bz2