From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kimball Thurston To: Andrew Cagney , Kimball Thurston , gdb@sources.redhat.com Subject: Re: gdb and dlopen Date: Wed, 17 Oct 2001 12:09:00 -0000 Message-id: References: <20011016161525.A1241@nevyn.them.org> <20011016213252.A8694@nevyn.them.org> <20011016220353.A9538@nevyn.them.org> <3BCCF83F.8010401@cygnus.com> <20011017010849.A23345@nevyn.them.org> <3BCDA6CF.3000308@cygnus.com> <20011017141550.B10927@nevyn.them.org> X-SW-Source: 2001-10/msg00180.html 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