From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30337 invoked by alias); 18 Apr 2012 18:12:59 -0000 Received: (qmail 30245 invoked by uid 22791); 18 Apr 2012 18:12:58 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-scoter.atl.sa.earthlink.net (HELO elasmtp-scoter.atl.sa.earthlink.net) (209.86.89.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Apr 2012 18:12:45 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SKZMy-0007Vc-6e; Wed, 18 Apr 2012 14:12:44 -0400 Message-ID: <4F8F0416.1080101@earthlink.net> Date: Wed, 18 Apr 2012 18:12:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pedro Alves 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> <4F8ECDDD.5010608@redhat.com> In-Reply-To: <4F8ECDDD.5010608@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94090baf76d7955c0aeec84c5022c570eee350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00130.txt.bz2 On 4/18/12 7:21 AM, Pedro Alves wrote: > 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. > I've not forgotten them! :-) I just wonder what the size numbers are really like. We haven't really had to address GDBserver size before, not least because it wasn't getting much attention and people were OK with all kinds of functionality simply being left out. Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected. But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more. Without a well-defined size target, and input from C++ mavens about minimum overheads, I don't think we can objectively say whether C++ is or is not acceptable for GDBserver. Stan