From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3333 invoked by alias); 14 Nov 2008 15:56:17 -0000 Received: (qmail 3282 invoked by uid 22791); 14 Nov 2008 15:56:16 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Nov 2008 15:55:33 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id mAEFqsKd022534; Fri, 14 Nov 2008 16:52:54 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id mAEFqrnp019171; Fri, 14 Nov 2008 16:52:53 +0100 (CET) Date: Fri, 14 Nov 2008 17:47:00 -0000 Message-Id: <200811141552.mAEFqrnp019171@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: stan@codesourcery.com, gingold@adacore.com, gdb-patches@sourceware.org In-reply-to: <20081114154308.GG12802@adacore.com> (message from Joel Brobecker on Fri, 14 Nov 2008 07:43:08 -0800) Subject: Re: [RFA] Darwin/x86 port (v2 - part 0) References: <3A152A70-4355-440D-839F-A4EAC36C530B@adacore.com> <200811131452.mADEq21U018058@brahms.sibelius.xs4all.nl> <406742BB-4F37-406B-B4E3-75C8DD2DBD03@adacore.com> <491C6C09.4050300@codesourcery.com> <2C387CFB-1541-41B5-964C-68692E078BFA@adacore.com> <491D93D8.6060007@codesourcery.com> <20081114154308.GG12802@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00346.txt.bz2 > Date: Fri, 14 Nov 2008 07:43:08 -0800 > From: Joel Brobecker > > (trying to take my AdaCore hat off) > > > My natural inclination is to accept the code into the trunk after review > > - I suspect that the next round of changes will be more invasive into > > the rest of GDB, and it would be easier to consider each of those > > separately from the basic port. But, I have a track record of being too > > optimistic on this strategy, ahem. :-) What do other people think? > > I think that's a good approach. In this case, it is even more attractive > as the changes have remained uninvasive so far, so it would be easy to > undo them all if we decided to do so. All in all, I think we have a lot > to gain, and little to lose. Just to be clear. I'm happy with the state the i386-specefic bits are in, so if Stan's happy with the generic Darwin bits I have no objections. Best to have this in the tree such that it is easier for other people to work on.