Re: gdb and dlopen

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Nov 19, 2001 at 12:38:21PM -0700, Kevin Buettner wrote:
> On Nov 19,  2:16pm, Daniel Jacobowitz wrote:
> 
> > > After I proposed the above idea, Peter Schauer emailed me privately
> > > and noted that my idea would "break setting breakpoints in global
> > > object constructor code in shared libraries."  He goes on to say
> > > that the "reenable breakpoint logic after every shlib load currently
> > > takes care of this."
> > > 
> > > So, it looks like you've also noticed one of the concerns that Peter
> > > had regarding my idea.
> > 
> > Yes.  I don't know what we can really do about this - besides
> > decreasing the total memory traffic for an update, which I think would
> > be wise.  Among other possibilities, do you have any comment on my
> > suggestion for setting inferior memory to be cached by default if not
> > otherwise specified?  Currently we default to uncached, which is safer,
> > but I can't think of many examples where it would be a problem to
> > cache.
> 
> Are you sure caching will help?  The cache has to be invalidated every
> time GDB stops, right?
> 
> If current_sos() is refetching some bit of memory more than once per
> invocation, then perhaps this problem should be solved by some other
> means?

I'm absolutely sure.  Or at least, I was... when I tested this, it was
an obvious win.  Now it is an obvious LOSS to turn on the cache.  I'm
not sure why, so I'll have to investigate it later.  In 5.0.90-cvs it
was a win and in current trunk it is a significant performance loss.

This is in the context of a linuxthreads application.  We do a
ridiculous, staggering amount of memory transfer in order to debug a
linuxthreads application, and parts of it are duplicated.

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