From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19576 invoked by alias); 11 Jul 2008 13:14:14 -0000 Received: (qmail 19568 invoked by uid 22791); 11 Jul 2008 13:14:14 -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 13:13:54 +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 m6BDDqjt015089; Fri, 11 Jul 2008 09:13:52 -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 m6BDDq2N024642; Fri, 11 Jul 2008 09:13:52 -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 m6BDDouu005691; Fri, 11 Jul 2008 09:13:51 -0400 Message-ID: <48775C98.9080209@gnu.org> Date: Fri, 11 Jul 2008 13:14:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Andrew STUBBS CC: gdb@sourceware.org Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <48772D22.1050602@st.com> In-Reply-To: <48772D22.1050602@st.com> 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/msg00115.txt.bz2 Andrew STUBBS wrote: > Tom Tromey wrote: >> I think GDB is nearly written in a dialect of C++ already: > > ... > >> In all these cases, the C++ code is, in my opinion, simpler to read >> and write than the corresponding gdb code. It is also more regular; >> whereas in gdb some "virtual methods" take a 'this' pointer, some do >> not; some classes have destructors, some do not (these are both things >> I ran into on the Python branch). Finally, C++ provides better >> support for abstraction, specifically via access control. > > I tend to agree with this statement. In particular I would say that > destructors would be much easier to follow than cleanups. > > I'm not going to make any judgement about whether there's a business > case for doing the work, but here's a question: > > A while ago there was some idea of a libgdb that would abstract the > debugger back end from the interface (or I may have totally > misunderstood what the whole thing was about). I haven't heard much > about it recently, and the libgdb that exists seems to be something of > a build artefact, rather than a useful abstraction. I think of it as a good high level concept, but yes, as Daniel points out, the libgdb implementation and approach are long dead. For instance, if gdb were more clearly broken into a number of components, we'd be able to implement tools such as gstack and gcore directly (as they were intended) and not as wrappers or hacks around the gdb cli. An initial step might be to clarify these internal interfaces, any thoughts on that? > If such an idea still exists, what affect would switching to C++ have > on that plan? Would it make it easier? Or would it just make it > incompatible with non-C++ projects? > I think it would help. For instance, Eclipse has started pushing a more abstract debugger interface - DSF - it expects the target to implement a very abstract O-O model of the target system. Being able to implement such an O-O models directly in an O-O language would greatly simplify things. Such an abstraction may even prove useful to the Python bindings, I'd imagine the combination of that and PyGtk to be a very empowering. -