deferred breakpoints

[Jim Ingham]

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