From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15623 invoked by alias); 26 Feb 2003 04:47:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15614 invoked from network); 26 Feb 2003 04:47:07 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by 172.16.49.205 with SMTP; 26 Feb 2003 04:47:07 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1Q4l6g7009310 for ; Tue, 25 Feb 2003 20:47:06 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 25 Feb 2003 20:47:06 -0800 Received: from apple.com (moleja.apple.com [17.201.22.21]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h1Q4l6f10816; Tue, 25 Feb 2003 20:47:06 -0800 (PST) Date: Wed, 26 Feb 2003 04:47:00 -0000 Subject: Re: deferred breakpoints Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: gdb@sources.redhat.com To: Kris Warkentin From: Jason Molenda In-Reply-To: <001e01c2dd3e$619dd640$2a00a8c0@dash> Message-Id: <287F12C4-4945-11D7-91F7-003065BC3540@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00555.txt.bz2 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