Re: gdb and dlopen

[Daniel Jacobowitz <drow at mvista dot com>]

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

child_xfer_memory is called for just about everything.  Why it's being
called in this particular case is another question, but I'm betting
we're rereading the link map.  With 50 dlopen'd libraries, stopping and
rereading the link map each time could be quite painful.  Kevin might
have something enlightening to say here, but I'll take a look at it.

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