From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13216 invoked by alias); 11 Jul 2007 19:47:58 -0000 Received: (qmail 13208 invoked by uid 22791); 11 Jul 2007 19:47:58 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jul 2007 19:47:54 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 55C67148120 for ; Wed, 11 Jul 2007 16:33:03 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6BJlgBq1331334 for ; Wed, 11 Jul 2007 16:47:43 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6BJj7fn015203 for ; Wed, 11 Jul 2007 16:45:08 -0300 Received: from hactar.local ([9.18.238.251]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6BJj75s015195; Wed, 11 Jul 2007 16:45:07 -0300 Subject: RE: GDB in C++ From: Thiago Jung Bauermann To: Gary Funck Cc: gdb@sourceware.org In-Reply-To: <00b601c7bda5$a5e6fa60$0a0a0a0a@DELORIAN> References: <00b601c7bda5$a5e6fa60$0a0a0a0a@DELORIAN> Content-Type: text/plain Date: Wed, 11 Jul 2007 19:47:00 -0000 Message-Id: <1184183253.5515.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 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: 2007-07/txt/msg00097.txt.bz2 On Tue, 2007-07-03 at 12:09 -0700, Gary Funck wrote: > If C++ isn't the answer, and keeping all of GDB in "C" is a fixed > point, what changes would the developers recommend that would > offer similar (perceived) improvements in understandability > and extensibility? Speaking as a newcomer who's trying to grasp GDB code, I think you made very good points. IMHO having reasonable internals documentation is a very good way to give an overview of GDB's organization and pitfalls. If GDB Internal's contents was transferred to the GDB wiki, maybe people would feel more compelled to update and expand it. I know I would try to contribute to it as I learn new stuff. The downside when comparing to patches against the existing documentation sources would be that peer review would be a bit more awkward (but there are ways around it). -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center