Re: gdb and dlopen

[Kimball Thurston <kimball@sgrail.com>]

At Wed, 17 Oct 2001 14:15:50 -0400,
Daniel Jacobowitz wrote:
> 
> On Wed, Oct 17, 2001 at 11:42:07AM -0400, Andrew Cagney wrote:
> > >thread_db is, plain and simply, horribly slow.  We could speed it up
> > >tremendously if we cached memory reads from the child across periods
> > >where we knew it was safe to do so; I'll have to think about how to do
> > >this.  Meanwhile, the real speed penalty seems to be:
> > 
> > Look at dcache.[hc].
> 
> Well, if I use dcache by creating an appropriate memory region, I go
> from 7.17 seconds execution time to 5.46 seconds.  We still do a load
> of unnecessary memory traffic, but at least it isn't quite so heinous.
> 
> Is there any reason not to define a Unix inferior process's memory
> space as cached by default?  I suppose that for mmap'd regions and for
> SYSV style shared memory we might lose, but I consider still consider
> this a reasonable behavior, worth documenting but not worth accepting a
> performance penalty for.

Along the same lines of just trying to clean up unnecessary work, I
was seeing 2 scans of all the open dsos for each dlopen call - it
looks like we are getting 2 BPSTAT_WHAT_CHECK_SHLIBS events (in
infrun.c) for each dlopen which causes us to rescan everything. Is
there a way to distinguish these two events, and only do the scan
once? 

- Kimball