From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10756 invoked by alias); 18 Apr 2012 14:10:13 -0000 Received: (qmail 10724 invoked by uid 22791); 18 Apr 2012 14:10:10 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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; Wed, 18 Apr 2012 14:09:55 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IE9rWf004203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 10:09:53 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3IE9pFR007187; Wed, 18 Apr 2012 10:09:51 -0400 Message-ID: <4F8ECB2F.2070406@redhat.com> Date: Wed, 18 Apr 2012 14:10:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Doug Evans CC: Daniel Jacobowitz , Pedro Alves , Jan Kratochvil , Tom Tromey , gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00111.txt.bz2 On 04/13/2012 01:04 AM, Doug Evans wrote: > On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz > wrote: >> The more things we add to gdbserver, the less I think it meets the >> goal of "simple, light-weight target agent". I resisted code sharing >> with GDB for a long time. If the consensus nowadays is that code >> sharing is the way to go, then I think it behooves someone to figure >> out the needs of a modern light-weight target agent that's a lot >> smaller than gdbserver. >> >> Yes, multiprocess debugging with gdbserver is an awesome development. >> No, you don't need it in the stage of system bringup where you don't >> have C++, if you're planning to have C++ eventually. So I think >> there's room for a potential C++ gdbserver and a small C gdbserver. > > [filing for reference sake] > > I'd (ultimately) like to see gdb and gdbserver built up out of a set > of, umm, libraries ("We need more libraries!"). I'm aiming torwards making the gdbserver backends be a library that is reused by both gdb and gdbserver. Gotta start somewhere. > Exporting the functionality of the libraries to scripting languages > (e.g., python) through these libraries would involve more of a C API > than C++. > > With said partitioning of functionality, it shouldn't be that hard to > have either a small and simple gdbserver or a large and feature-rich > gdbserver. Exactly. -- Pedro Alves