From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21856 invoked by alias); 11 Jan 2011 23:35:14 -0000 Received: (qmail 21772 invoked by uid 22791); 11 Jan 2011 23:35:13 -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; Tue, 11 Jan 2011 23:35:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 07ED02BABED; Tue, 11 Jan 2011 18:35:08 -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 W9eEJXhhtmRO; Tue, 11 Jan 2011 18:35:07 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E89622BABA0; Tue, 11 Jan 2011 18:35:07 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id ADDEC1459AD; Wed, 12 Jan 2011 03:35:07 +0400 (RET) Date: Tue, 11 Jan 2011 23:38:00 -0000 From: Joel Brobecker To: Doug Evans Cc: "Frank Ch. Eigler" , Yao Qi , "gdb-patches@sourceware.org" Subject: Re: duplicated code in gdb and gdbserver Message-ID: <20110111233507.GD2331@adacore.com> References: <4D272FF6.3070402@codesourcery.com> <20110110155413.GE17302@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-01/txt/msg00239.txt.bz2 > And with such a library, I'd make it so that "non-gdb tools" could use > it too. For example, it would make easier the building of gdbservers > that need to speak something other than the remote protocol. I'm not entirely crazy about the idea of a public API, mostly because I would prefer to avoid compatibility issues when making changes. This is an extra constraint that I'd like to avoid unless we know some projects would benefits in ways that they cannot with approaches that are currently available. What I would much rather see, is something that allows projects to easily implement the client-side part of the remote protocol. That could even be done independently from GDB, much like GDB/MI parsers are being implemented independently from GDB. -- Joel