From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2622 invoked by alias); 30 May 2011 15:55:20 -0000 Received: (qmail 2610 invoked by uid 22791); 30 May 2011 15:55:19 -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; Mon, 30 May 2011 15:54:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B7DB02BB1BB; Mon, 30 May 2011 11:54:51 -0400 (EDT) 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 hOGy7rZ9Cvky; Mon, 30 May 2011 11:54:51 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6D8742BB179; Mon, 30 May 2011 11:54:51 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E0FA4145615; Mon, 30 May 2011 08:54:48 -0700 (PDT) Date: Mon, 30 May 2011 15:55:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Thiago Jung Bauermann , Yao Qi , gdb-patches@sourceware.org Subject: Re: [patch] Remove HAVE_UINTPTR_T from gdb_thread_db.h Message-ID: <20110530155448.GB2620@adacore.com> References: <4DCE1F43.1000301@codesourcery.com> <20110514170722.GD19356@adacore.com> <4DD0B8D8.9060004@codesourcery.com> <1306431533.2008.18.camel@hactar> 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-05/txt/msg00681.txt.bz2 > Thiago> I'm not familiar with gdbserver but would it make sense to make > Thiago> gdbserver internally use the target_ops vector? That would make GDB's > Thiago> -nat.c files usable without modification in gdbserver. Then it would be > Thiago> a matter of porting the gdbserver's additional features which GDB native > Thiago> doesn't have. > > The idea makes sense; I think it is among those discussed in previous > threads on this topic. > > The devil is in the details. The *-nat.c files are free to use any > other facility provided by gdb. So, perhaps this approach would bloat > gdbserver excessively. I think that the target_ops vector does a lot more than what gdbserver needs to do. So they way I have been thinking about it, in conceptual terms, is to incorporate the gdbserver's target vector into GDB's target vector. In practice, it's probably going to be something different, but I see the future as gdbserver being a module inside GDB. and the GDBserver executable can be that module with the extra remore-protocol implementation on top of that. -- Joel