From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 494 invoked by alias); 24 Feb 2011 04:32:27 -0000 Received: (qmail 486 invoked by uid 22791); 24 Feb 2011 04:32:26 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Feb 2011 04:32:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A17952BACF8; Wed, 23 Feb 2011 23:32:18 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4fy6aP7jzHXd; Wed, 23 Feb 2011 23:32:18 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 314062BACEB; Wed, 23 Feb 2011 23:32:18 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4197E1459B0; Thu, 24 Feb 2011 08:32:08 +0400 (RET) Date: Thu, 24 Feb 2011 05:11:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: yao@codesourcery.com, gdb-patches@sourceware.org Subject: Re: [patch] Move common macros to i386-common.h Message-ID: <20110224043208.GX2600@adacore.com> References: <4D57AB12.1050708@codesourcery.com> <4D649A89.6040909@codesourcery.com> <201102232117.p1NLHdhA015543@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102232117.p1NLHdhA015543@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-02/txt/msg00673.txt.bz2 > I'm particularly worried about changes I'll make myself. [...] > Sharing architecture-specific #define's is probably fine. Sharing > some simple basec support functions may also be ok. But I don't think > sharing more complicated code (such as the code manipulating the i386 > debug registers) is a good idea. I think (hope!) that this would be a transitionary problem, and I am willing to take on any breakage inadvertandly introduced - We do gdbserver builds nightly and I update our sources every week or so. But I think we should share the complicated code, simply because it is getting increasingly complex, thanks to new features such as non-stop, tracepoints, or older features such as threading support which evolve as the kernel capabilities evolve. And while we're at it, why would we want to continue writing the same code twice? Right now, we have some bugs in GDB but not in GDBserver, some bugs in GDBserver but not GDB, and some bugs in both. Everytime we have a bug in one of them, but not the other, we just look at how we deal with the situation in the other, and back-port the idea. Or, when the bug is in both, we have to fix the problem twice, except that the API is different, and thus we do the work twice. My view of the direction we should take is that we should have the same API for doing all the target stuff: start inferior, next/step/cont, read/write register/memory, get shared libraries, tracepoints, watchpoints, etc. Once both use this API, then the remaining part of GDBserver should be the common code that implements the stub-side of the remote protocol, which should pretty much build out-of-the-box on any OS. The consequence of that should be that, once you port GDB, you pretty much get GDBserver for free. And the other consequence is if you decided to port GDBserver only as a first step, you wouldn't have to do the work again when you decide to port GDB. -- Joel