From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27521 invoked by alias); 10 Jan 2011 16:35:06 -0000 Received: (qmail 27345 invoked by uid 22791); 10 Jan 2011 16:35:03 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Jan 2011 16:34:58 +0000 Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p0AGYt8h029922 for ; Mon, 10 Jan 2011 08:34:55 -0800 Received: from vws16 (vws16.prod.google.com [10.241.21.144]) by hpaq2.eem.corp.google.com with ESMTP id p0AGWu9q023134 for ; Mon, 10 Jan 2011 08:34:54 -0800 Received: by vws16 with SMTP id 16so8150955vws.19 for ; Mon, 10 Jan 2011 08:34:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.95.200 with SMTP id e8mr25024573qcn.213.1294677293567; Mon, 10 Jan 2011 08:34:53 -0800 (PST) Received: by 10.220.118.80 with HTTP; Mon, 10 Jan 2011 08:34:53 -0800 (PST) In-Reply-To: <20110110155413.GE17302@redhat.com> References: <4D272FF6.3070402@codesourcery.com> <20110110155413.GE17302@redhat.com> Date: Mon, 10 Jan 2011 16:35:00 -0000 Message-ID: Subject: Re: duplicated code in gdb and gdbserver From: Doug Evans To: "Frank Ch. Eigler" Cc: Yao Qi , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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/msg00191.txt.bz2 On Mon, Jan 10, 2011 at 7:54 AM, Frank Ch. Eigler wrote: > dje wrote: > >> > [...]=EF=BF=BDA library API for the remote protocol [...]. >> >> Yeah, like Joel, it isn't clear what is meant here. >> Can you elaborate? > > Just that non-gdb tools needing to perform remote process control > could speak to gdbserver too, mediated if necessary by a new library > slightly abstracting the TCP/IP stuff. So native "gdb hello" would have to fork gdbserver. Ah. That is one way to go. It would give us the impetus to get multiprocess debugging across fork working well (which Tom wants for gcc). 1/2 :-) 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 t= oo. For example, it would make easier the building of gdbservers that need to speak something other than the remote protocol.