deferred breakpoints

deferred breakpoints

[Kris Warkentin]

How difficult do you think deferred breakpoints would be to implement?  We
have a customer who does a lot of work with shared objects and they'd like
to be able to set breakpoints in them and have them persist across runs.
I'm thinking that creating a list of breakpoints that could be run through
every time a shared object was loaded would do the trick.  Can anyone point
out any obvious gotcha's?

Kris

Re: deferred breakpoints

[Daniel Jacobowitz]

On Tue, Feb 25, 2003 at 03:55:32PM -0500, Kris Warkentin wrote:
> How difficult do you think deferred breakpoints would be to implement?  We
> have a customer who does a lot of work with shared objects and they'd like
> to be able to set breakpoints in them and have them persist across runs.
> I'm thinking that creating a list of breakpoints that could be run through
> every time a shared object was loaded would do the trick.  Can anyone point
> out any obvious gotcha's?

I'll do you one better - Apple posted patches for this some time ago,
they can probably dig out an updated version for you if you inquire. 
It was called "future break".


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: deferred breakpoints

[Kris Warkentin]

I took a look at the sources from apple and it looks like what they're doing
is relatively simple.  I think most of the wiring is already in gdb.

1) Attempt to set break. If that fails:
2) Create a raw breakpoint and set it to be shlib_disabled.  That way gdb
attempts to reset it every time a shlib is loaded.

I believe that you might get a lot of error messages with this method when
gdb complains about not being able to set the breakpoints but I may be
wrong.  The relevant code is below.  Interesting.  I'll see if I can do it
with a newer version (the apple source is for gdb-4.18)

cheers,

Kris

      struct symtab_and_line sal =
      {0, 0};
      struct breakpoint *b = set_raw_breakpoint (sal);

      printf_unfiltered
 ("Will attempt to resolve \"%s\" on future dynamic loads.\n", args);

      b->number = ++breakpoint_count;
      b->addr_string = savestring (args, strlen (args));
      b->enable = shlib_disabled;
      b->inserted = 0;
      b->disposition = donttouch;
      b->type = bp_breakpoint;
      if (modify_breakpoint_hook)
 modify_breakpoint_hook (b);

> How difficult do you think deferred breakpoints would be to implement?  We
> have a customer who does a lot of work with shared objects and they'd like
> to be able to set breakpoints in them and have them persist across runs.
> I'm thinking that creating a list of breakpoints that could be run through
> every time a shared object was loaded would do the trick.  Can anyone
point
> out any obvious gotcha's?
>
> Kris
>

Re: deferred breakpoints

[Jason Molenda]

Hi Kris,

Our developers use the future-breaks a lot here at Apple, they work 
well for the sort of problem you're looking at.


> I'll see if I can do it with a newer version (the apple source is for 
> gdb-4.18)

Our cvs repository is publicly readable.  You have to register first, 
which is lame but it's just an arbitrary token so they can gauge 
community interest:
	http://www.opensource.apple.com/apsl/

Then you access it via pserver:
	http://developer.apple.com/darwin/tools/cvs/read-only.html

(the module to check out is "gdb").

Klee did the last merge with the FSF just a few weeks back, so these 
are pretty current sources.


Jason

Re: deferred breakpoints

[Kris Warkentin]

> Our developers use the future-breaks a lot here at Apple, they work
> well for the sort of problem you're looking at.

Thanks for responding Jason.  I'm curious: are these patches in use at Apple
not considered suitable for submission to the FSF?  I'm just wondering why
you maintain a separate tree rather than pushing everything out.  We're
trying hard to get all our changes rolled in to avoid the hassle of having a
separate tree.

cheers,

Kris

Re: deferred breakpoints

[Jason Molenda]

On Tuesday, February 25, 2003, at 06:25  PM, Kris Warkentin wrote:

> I'm curious: are these patches in use at Apple not considered suitable 
> for submission to the FSF?

In the case of future-break, it was submitted at one point, along with 
a command to save breakpoints to a file as gdb commands:
	http://sources.redhat.com/ml/gdb-patches/2001-12/msg00296.html

I haven't re-read the whole discussion that ensued to remember what 
happened, but you can probably guess what the final outcome was. :-)

> I'm just wondering why you maintain a separate tree rather than 
> pushing everything out.

I think any company supporting the tools for any length of time will 
have an internal fork.  There are going to be customer-driven demands 
for features or changes that will not be accepted in the main line 
sources.  Buddha knows Cygnus (now a part of Red Hat) had vast 
differences in our internal gcc repository, and I'd be surprised if RH 
doesn't still today have an internal repository for such work on gdb or 
binutils.

There will always be some changes in the Apple gdb that won't be 
accepted in the FSF sources, so there will always be a separate Apple 
gdb.

Of course, merging between these two repositories and fixing the bugs 
that pop up is a huge time burden (i.e. costs real money of Apple), so 
it's in our best interest to keep in sync with the mainline, and to 
move our fixes up to the FSF as much as possible.

Unfortunately the Apple gdb group is really small and we can't allocate 
lots of time to champion our local changes back into the FSF sources, 
so many of our changes haven't been submitted yet.  We've been shipping 
an IDE (Project Builder) whose debugger UI uses gdb via MI for at least 
two years now, and we've done a lot of work at making MI really 
work--that's without a doubt the most significant bit of code we have 
in our tree that the FSF sources could benefit from IMHO.  Some of it 
is getting migrated over, cf the work by Keith and Elena and others for 
the interpreter mode stuff, but there is a lot more we've done.

I don't want to re-open the debate into patch responsiveness, but 
honestly, it is hard to get management to allocate a lot of time to 
pushing patches back to the FSF when it can seem so futile at times... 
Mgmt is sold on the idea that we need to minimize divergence, and 
merging and submitting patches is an accepted part of doing business 
with free software, but the amount of time it's taken to get things in 
seems a little disproportionate at times.


> We're trying hard to get all our changes rolled in to avoid the hassle 
> of having a separate tree.

Yes, yes, a very good goal, no one here at Apple will disagree with 
that.

Jason

Re: deferred breakpoints

[Kris Warkentin]

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

Re: 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