Re: gdb and dlopen

Kimball Thurston
2001-10-17T12:09:00Z

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