From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20163 invoked by alias); 18 Apr 2012 14:22:06 -0000 Received: (qmail 20148 invoked by uid 22791); 18 Apr 2012 14:22:03 -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:21:45 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3IELJtG007981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 10:21:19 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3IELHDa017674; Wed, 18 Apr 2012 10:21:18 -0400 Message-ID: <4F8ECDDD.5010608@redhat.com> Date: Wed, 18 Apr 2012 14:22: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: Stan Shebs CC: gdb@sourceware.org Subject: Re: Will therefore GDB utilize C++ or not? References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F836F72.8080700@earthlink.net> In-Reply-To: <4F836F72.8080700@earthlink.net> 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/msg00113.txt.bz2 On 04/10/2012 12:23 AM, Stan Shebs wrote: > On 4/4/12 1:47 PM, Tom Tromey wrote: >> I don't believe we should convert all of GDB to C++. In particular I >> think gdbserver should remain as pure C, and likewise any code shared >> between gdbserver and gdb should be kept as such. > > I don't know that it matters that much for GDBserver anymore. When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today. You're forgetting about all those uclibc (and musl's and other libc's of the world) targets that most probably don't even have a display, and some which don't support C++, and that still need to be debugged. A debugger agent is a system component that should aim lower than a bloated browser. Again, even the Android NDK doesn't support C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago), one of the biggest justifications for a C++ move. > Plus I note that GDBserver is picking up a load of functionality, and the truly space-conscious are better-advised to build a custom stub that is stripped down to just the bits they're going to use. If that's a concern, we can make the load of functionality build time optional. Heck, the Linux kernel can scale from tiny machines to the super computers of the world that way (and that no doubt contributes very much to its ever-growing ubiquitousness). I see no reason gdbserver can't. -- Pedro Alves