From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17330 invoked by alias); 12 Apr 2012 20:06:32 -0000 Received: (qmail 17320 invoked by uid 22791); 12 Apr 2012 20:06:31 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ee0-f41.google.com (HELO mail-ee0-f41.google.com) (74.125.83.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Apr 2012 20:06:18 +0000 Received: by eeke53 with SMTP id e53so654626eek.0 for ; Thu, 12 Apr 2012 13:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.119.197 with SMTP id n45mr568189eeh.46.1334261176685; Thu, 12 Apr 2012 13:06:16 -0700 (PDT) Received: by 10.14.38.213 with HTTP; Thu, 12 Apr 2012 13:06:16 -0700 (PDT) In-Reply-To: <4F833D29.4050102@redhat.com> References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <20120409190519.GA524@host2.jankratochvil.net> <4F833D29.4050102@redhat.com> Date: Thu, 12 Apr 2012 20:06:00 -0000 Message-ID: Subject: Re: Will therefore GDB utilize C++ or not? From: Daniel Jacobowitz To: Pedro Alves Cc: Jan Kratochvil , Tom Tromey , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00088.txt.bz2 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. =A0We don't want there to need to be other gdbserver-l= ike >>> programs specialized for such environments, and gdbserver to be usable = only >>> on bigger machines. =A0We want gdbserver to run everywhere. =A0And #2, = the debugger >>> is one of the first programs that is desirable to get running on a new >>> system/board. =A0Usually 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". 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. How did I end up being the curmudgeon? I'm confused. --=20 Thanks, Daniel