Re: gdb and dlopen

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Nov 19, 2001 at 10:04:09AM -0700, Kevin Buettner 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.

> The only thing that I can think of is to introduce a GDB setting which
> indicates which behavior you want.  Maybe call it
> "solib-reenable-breakpoints-after-load" and have it default to "true". 
> (Which is what it currently does.)
> 
> Then, if you care more about speed, you can shut it off if desired.
> 
> Thinking about it some more, maybe it would be better extend
> auto-solib-add so that it has three settings:
> 
>     disabled			(off)
>     when-stopped
>     as-early-as-possible	(on)

I suppose this is a good idea.  I'm not going to do it, as I'd much
rather make as-early-as-possible (which is what I've wanted nine times
out of ten when actually debugging something which used DSOs...)
faster.

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