From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13442 invoked by alias); 11 Jul 2008 14:27:26 -0000 Received: (qmail 13122 invoked by uid 22791); 11 Jul 2008 14:27:25 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 14:27:08 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6BER5YS013388; Fri, 11 Jul 2008 10:27:05 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BER53Z019842; Fri, 11 Jul 2008 10:27:05 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BER4gr029461; Fri, 11 Jul 2008 10:27:04 -0400 Message-ID: <48776DC1.1070606@gnu.org> Date: Fri, 11 Jul 2008 14:27:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Vladimir Prus CC: gdb@sources.redhat.com 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> In-Reply-To: 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/msg00117.txt.bz2 Vladimir Prus wrote: > Joel Brobecker wrote: > > >> I am way out of my league on this, but isn't it the case that: >> - there's still some progress to be made to help debugging C++ >> in general (I might be VERY wrong on that one) >> > > These are good points. They offer pointers to some of the areas that GDB is lacking. The cheap comment to make here though is that, were GDB written in C++ and used these features, we'd have these debugging problems fixed - of course, for instance, GDB is managing to be a good Ada debugger, without being written in Ada :-) This does, I think, raise an interesting question: is, or should, be being the a good (best?) C++ debugger be a high priority for GDB? > I think that the biggest issue with debugging C++ is that whenever you > have pointer to class Base, which actually points to object of class > Derived, and you want GDB to print the real type, GDB gives fits. > (Or maybe, I'm not sufficiently trained in asking GDB politely). > > Second issue is that I don't think "step" via throw statement works -- you > need "catch catch". > > I don't think the above issues are showstoppers -- there are workarounds, > and the issues must be fixed anyway. > > The inline functions are not specific to C++, and templates -- well, there > are no issues debugging templates, and who needs templates outside of > (well-debugged already) STL, anyway (*)? > > Last time I checked, GDB had some bizarre logic to handle C++ namespaces, > but well, who needs namespaces (*)? > > - Volodya > > (*) Both templates and namespaces have important uses; but it does not seem > GDB, specifically, has much need of them. > > > > >