Re: deferred breakpoints

Jim Ingham
2003-03-01T02:16:43Z

Kris,

That sounds fine. PB does that for all the GUI type breakpoints (where
the user actually clicks in a source window gutter somewhere). It goes
a little further, because it also knows what shared
library(s)/executable that file got build into, so it just waits for
that to get loaded before inserting the breakpoint.

One thing that you will have to be careful about when you are getting
the GUI to stop for shared library events is that when the user does a
"next" over a function that causes a shared library load, you are
probably going to lose control of the inferior and set it running. The
reason for this is that completing the "next" over the function is
implemented by a special breakpoint (step-resume). However, when the
target "really" stops, it deletes the step resume breakpoints (since
you might step again, and they don't stack). However, stopping when
you have stop-on-solib-event set to "true" is considered a "real" stop
- as indeed it is since the user regains total control. So then when
the GUI resumes, the step-resume breakpoint gets deleted, and there is
nothing to stop it anymore, so it just continues.

This doesn't happen often, but it is really annoying when it does...

I worked around this by adding a solib-step-bp and a solib-finish-bp,
and by "transferring" the step-resume breakpoint to one of these as
appropriate, you catch again. I am not sure this is the right way to
do it, because you run the risk of stranding these breakpoints (as you
would with the step-resume breakpoints...) Might be better to have an
"I promise all I am going to do is continue" type flag and when you hit
the solib and stop, you remind yourself NOT to remove the step-resume
breakpoints. You will also have to remember to hold onto the stepping
range so you will step to the end of the source line (the step-resume
breakpoint in on the return from the called function which is often not
the line end...)

Hope this helps,

Jim

On Thursday, February 27, 2003, at 06:23 AM,
gdb-digest-help@sources.redhat.com wrote:

> From: Kris Warkentin <kewarken@qnx.com>
> Date: Wed Feb 26, 2003 8:51:54 AM US/Pacific
> To: Jason Molenda <jmolenda@apple.com>
> Cc: gdb@sources.redhat.com
> Subject: Re: deferred breakpoints
>
>
> Looks like it might be a moot point. Deferred breakpoints are
> implementable
> from the ide side of things just by keeping an internal list of
> breakpoints
> and then attempting to apply them whenever there is a shlib event.
> Eclipse
> keeps breakpoints associated with libs and apps in its metadata so they
> persist across invocations so no special wiring in gdb will be
> required.
>
> cheers,
>
> Kris
>
--
Jim Ingham jingham@apple.com
Developer Tools
Apple Computer