Re: deferred breakpoints

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

gdb detach

[Smita]

Hi,
	I was wondering if there is a way to detach a process from gdb
from outside the gdb process? Or is there a way to find out the pid of
the gdb process that is controlling a process (i.e. when a process attched
to gdb)
	Please forgive me if this the wrong group for this question.
Thanks
Smita

On Tue, 25 Feb 2003, Kris Warkentin wrote:

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