From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22220 invoked by alias); 12 Jul 2008 05:41:56 -0000 Received: (qmail 22210 invoked by uid 22791); 12 Jul 2008 05:41:55 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 12 Jul 2008 05:41:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9F0242A9704; Sat, 12 Jul 2008 01:41:32 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tyLeUd0-9VZZ; Sat, 12 Jul 2008 01:41:32 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 3507C2A96E8; Sat, 12 Jul 2008 01:41:32 -0400 (EDT) Message-ID: <4878440A.2060206@adacore.com> Date: Sat, 12 Jul 2008 05:41:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Dave Korn , 'Joel Brobecker' , 'Mark Kettenis' , stanshebs@earthlink.net, gdb@sourceware.org Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <48766A88.1050402@earthlink.net> <200807102153.m6ALrjjm017722@brahms.sibelius.xs4all.nl> <20080711062612.GB6132@adacore.com> <003001c8e370$61fcaa10$2708a8c0@CAM.ARTIMI.COM> <20080711162546.GA13678@caradoc.them.org> In-Reply-To: <20080711162546.GA13678@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-07/txt/msg00135.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Jul 11, 2008 at 05:08:39PM +0100, Dave Korn wrote: >> I think the real issue is that GDB has to be able to debug itself and GDB >> is currently weak in a few important areas of C++ support. I think that >> should be resolved before we consider porting the code. > > I don't think it's a big issue. The biggest problems have been > resolved; additional problems are mostly in bits of C++ that we would > probably avoid anyway. In fact it can just be a criterion for what features in C++ to allow that they must be easily debuggable. If a move to C++ for GDB and possibly other similar projects is made, and a well established subset prescribed, it may well be worth having a switch built into g++ to enforce this subset (similar to the use of -gnatg in Ada, although that does not go as far as it might in enforcing the use of the allowed Ada subset for the compiler itself. >