From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9320 invoked by alias); 18 Apr 2012 14:08:34 -0000 Received: (qmail 9294 invoked by uid 22791); 18 Apr 2012 14:08:31 -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:07:52 +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 q3IE7oAH002524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 10:07:50 -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 q3IE7mC2006537; Wed, 18 Apr 2012 10:07:49 -0400 Message-ID: <4F8ECAB4.4020605@redhat.com> Date: Wed, 18 Apr 2012 14:08: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: Daniel Jacobowitz CC: 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/msg00110.txt.bz2 On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote: > On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves wrote: >> On 04/09/2012 08:05 PM, Jan Kratochvil wrote: >> >>> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote: >>>> Indeed, gdbserver would need to remain pure C, >>> [...] >>>> This is important, because we want gdbserver to be usable >>>> in #1, resource constrained scenarios where the C++ dependency would >>>> be unacceptable. We don't want there to need to be other gdbserver-like >>>> programs specialized for such environments, and gdbserver to be usable only >>>> on bigger machines. We want gdbserver to run everywhere. And #2, the debugger >>>> is one of the first programs that is desirable to get running on a new >>>> system/board. Usually you get C going much sooner than C++. > > The more things we add to gdbserver, the less I think it meets the > goal of "simple, light-weight target agent". Most things we add to gdbserver are optional. E.g., tracepoints, and the accelerated DSO list reading. It'd be simple to add a --bare-bones configure switch that disabled all the optional features. > 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. I don't think multiprocess debugging adds much in terms of code size. It touches a lot, because it paremetrizes things with additional structures instead of globals, but mostly, that's it. A lot of code needed to _change_, not be added. > So I think > there's room for a potential C++ gdbserver and a small C gdbserver. Seriously, I'd very very much like to fuse GDB's and GDBserver's backends, to eliminate the duplication, which really gets in the way. I should know; adding multi-process and non-stop to gdbserver wasn't that much accelerated from having added it to gdb itself, given how the codebases are similar, yet so different. So on order to remove the duplication, we'd end up with _two_ gdbservers, written in different languages, each with its own bugs and need for maintenance, adding of new arch ports, etc.? Doesn't seem like a net win to me. :-) -- Pedro Alves