From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17998 invoked by alias); 30 Jul 2008 19:42:51 -0000 Received: (qmail 17990 invoked by uid 22791); 30 Jul 2008 19:42:50 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 19:42:27 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m6UJgIHB014508; Wed, 30 Jul 2008 21:42:18 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m6UJgH6s005159; Wed, 30 Jul 2008 21:42:17 +0200 (CEST) Date: Wed, 30 Jul 2008 19:56:00 -0000 Message-Id: <200807301942.m6UJgH6s005159@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: stanshebs@earthlink.net CC: eliz@gnu.org, gdb@sources.redhat.com In-reply-to: <4890B6BB.7010603@earthlink.net> (message from Stan Shebs on Wed, 30 Jul 2008 11:45:15 -0700) Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@gnu.org> <488F70E6.7060801@earthlink.net> <4890B6BB.7010603@earthlink.net> 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: 2008-07/txt/msg00337.txt.bz2 > Date: Wed, 30 Jul 2008 11:45:15 -0700 > From: Stan Shebs > > Eli Zaretskii wrote: > >> Date: Tue, 29 Jul 2008 12:35:02 -0700 > >> From: Stan Shebs > >> CC: gdb@sources.redhat.com > >> > >> For instance, at this very moment I'm looking at > >> ALL_OBJFILES and friends, wondering if the introduction of multiple > >> execs is going to impact overall performance. > >> > > > > And how would that change with C++? > > > > > C++ collection classes would be very effective here. And sure, the same > things could be constructed manually in C, but then you're using piles > of macro trickery a la vec.h and you lose all your typechecking etc, or You mean the C++ STL container classes? Yes they make it easy to write code. But they don't really help when you need to debug your code since they are implemented using templates. The result is incomprehensible compiler errors when you make a mistake in your code. And every time I need to look at such a container in GDB I spend minutes and minutes figuring out how to display its contents. I'm not a fan of macro trickery a la vec.h either. I think actually "open coding" your containers is preferable in many cases. Linked lists and dynamically sizable arrays aren't too difficult to implement of you only need them for two or three different types. > if you use function dispatching to iterate, you blow your optimization > opportunities in code that is known to be time-critical. Do you have any evidence to back this up? As far as I understand the main optimization strategy for C++ is heavy use of inlining. This increases the code footprint of your code which in turn blows away your instruction cache. That's a heavy price to pay for avoiding a few branch instructions and some stack access. My experience is the exact opposite. Behind that simple assignment might hide a very costly operation. > Good use of C++ > machinery effectively moves functionality out of the GDB source tree and > lets the compiler do the work instead. Pushing compile time through the roof and gobbling up several hundred of megabytes of memory. Will it still be possible to compile a native GDB on an underpowered ARM CPU with 64MB of memory?