From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23280 invoked by alias); 10 Jan 2011 19:02:00 -0000 Received: (qmail 23249 invoked by uid 22791); 10 Jan 2011 19:02:00 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Jan 2011 19:01:52 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0AJ1eLe013312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jan 2011 14:01:40 -0500 Received: from fche.csb (vpn-8-67.rdu.redhat.com [10.11.8.67]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0AJ1ehs024230; Mon, 10 Jan 2011 14:01:40 -0500 Received: by fche.csb (Postfix, from userid 2569) id 886A558153; Mon, 10 Jan 2011 14:01:39 -0500 (EST) Date: Mon, 10 Jan 2011 19:02:00 -0000 From: "Frank Ch. Eigler" To: Doug Evans Cc: Yao Qi , "gdb-patches@sourceware.org" Subject: Re: duplicated code in gdb and gdbserver Message-ID: <20110110190139.GF17302@redhat.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.4.2.2i 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/msg00198.txt.bz2 Hi, Doug - dje wrote: > [...] > Still, in the end it seems more complicated than having gdb link in > the same library that gdbserver does. > And with such a library, I'd make it so that "non-gdb tools" could > use it too. That's true. > For example, it would make easier the building of gdbservers that > need to speak something other than the remote protocol. I guess it depends on how many new abstractions one wishes to invent. The remote protocol is well-proven, so experimental design is not needed. New protocols may have associated state machines that are sufficiently close to the remote protocol that one can bridge to them easily, or sufficiently far that gdb infrun/core changes would be needed. It depends. Until one comes along though, I would propose going with what we know. - FChE