This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: deferred breakpoints
- From: Jason Molenda <jmolenda at apple dot com>
- To: Kris Warkentin <kewarken at qnx dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 25 Feb 2003 20:45:41 -0800
- Subject: Re: deferred breakpoints
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