From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1294 invoked by alias); 13 Apr 2012 00:04:38 -0000 Received: (qmail 1284 invoked by uid 22791); 13 Apr 2012 00:04:37 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Apr 2012 00:04:22 +0000 Received: by vbbey12 with SMTP id ey12so2172991vbb.0 for ; Thu, 12 Apr 2012 17:04:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=tibBYJEFa0wa2aVeL3mJuA58gqHPQ4tjNBVQbhQlYL4=; b=eVJ7U/YdJNTXxkqF7WcRd8vXNeXR9guAMx6A8ldNwlwLD06u1epzziw/C0z33xRv/z cRj4JYrcmivfE+OrU/Lq1HAN5HF0VqRn8g2GCq85i8rTFAKk2L4fF4yYu0nfJV5IHDG4 kT9ZIpY5b0Kpu37JvuOgTW1HL9i3ZgyZsbVAQqOTwxxDQrpbwK+hWwCidoHF/9FroAp8 3wC1xLz5XFBdEQFcZBM7aYC8x5jVw7cqqV8Dm64qfUlQSX38KbD5j+Ct4VxswGCFKe6Q S4xPi2VNsLM4hdmZ77IZ5+XiTfDpkrkcv4UN6qbuXdB+gMW38ruLSNtpEEXju7t8vnox QxUQ== Received: by 10.52.175.138 with SMTP id ca10mr47849vdc.114.1334275461606; Thu, 12 Apr 2012 17:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.138 with SMTP id ca10mr47834vdc.114.1334275461382; Thu, 12 Apr 2012 17:04:21 -0700 (PDT) Received: by 10.220.7.66 with HTTP; Thu, 12 Apr 2012 17:04:21 -0700 (PDT) In-Reply-To: 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: Fri, 13 Apr 2012 00:04:00 -0000 Message-ID: Subject: Re: Will therefore GDB utilize C++ or not? From: Doug Evans To: Daniel Jacobowitz Cc: Pedro Alves , Jan Kratochvil , Tom Tromey , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmgO13OI+93LfnIh1bNUXdY6fD+35o+i83/vaQDYt54nQhmsMPRWqCsoeM3GcEUUUFfs/vizthgzMaaU25euChSeKmW2uHyusiSE2dp8Q1AgQuGclwwfW2rdrBVFpdhQMtXVCOE 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/msg00090.txt.bz2 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". =A0I resisted code sharing > with GDB for a long time. =A0If 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. =A0So 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!"). 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. [side question: Do people that want a small embedded-system-like gdbserver, also want it to have same features as the the massively feature rich gdbserver of a non-embedded-system gdbserver? I'd expect that they're ok that the overarching need of smallness precluding some, umm, bloatware. :-)]