This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]