From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 761 invoked by alias); 31 Jul 2008 14:37:50 -0000 Received: (qmail 752 invoked by uid 22791); 31 Jul 2008 14:37:49 -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; Thu, 31 Jul 2008 14:37:24 +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 m6VEbMM1020339; Thu, 31 Jul 2008 10:37:22 -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 m6VEbMSF030714; Thu, 31 Jul 2008 10:37:22 -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 m6VEbLI5031472; Thu, 31 Jul 2008 10:37:21 -0400 Message-ID: <4891CE20.8040308@gnu.org> Date: Thu, 31 Jul 2008 15:37:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Stan Shebs CC: Eli Zaretskii , gdb@sources.redhat.com 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> <4890C127.80404@earthlink.net> In-Reply-To: <4890C127.80404@earthlink.net> 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/msg00350.txt.bz2 Stan Shebs wrote: > >> >> > How can I do that meaningfully? It depends on how everything else is > to be designed. I'm a little surprised that you don't see it yourself, > actually. I think Eli's point is reasonable, we need good reason to change the code; multi-arch, for instance, was motivated by the desire to support multiple architectures within a single GDB. Below are two candidates for change; In each case they provide design suggestions that, I believe, are more easily expressed using an O-O paradime, and let us address specific limitations in the current GDB code value has-a location has-a-multiple pieces http://sourceware.org/ml/gdb/2008-07/msg00302.html By breaking up value so that it's location consists of multiple pieces we're able to handle the modification of variables who's value is split between registers, or between registers and memory. I think this provides an example of where we can ignore the language and focus on the proposed design change, deciding if it stands up on its merits. A C++ implementation, while perhaps more straight forward, isn't a predicate to the work. virtual stack vs physical stack http://sourceware.org/ml/gdb/2008-07/msg00191.html This offers both an alternative to Daniel's current inline back-trace code; and a way potential way forward for us to handle more complex unwinding such as can occure in an OpenMP program where the user's stack appears to straddle multiple threads. This design is more powerful in that it applies the decorator pattern; something that may be technically challenging in C. For each case, especially the second, is this more straight forward in an O-O language, even C++. >>> And sure, the same things could be constructed manually in C, but >>> then you're using piles of macro trickery a la vec.h >>> >> >> Are we still talking about ALL_OBJFILES, or about something more >> broad? ALL_OBJFILES is just a loop: >> >> #define ALL_OBJFILES(obj) \ >> for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next) >> > It's the the "and friends" part that is problematic, there are a dozen > variants at least, and the potential for doubling that number with > multiple execs, because sometimes you still want to iterate through > all indiscriminately, other times through only the objfiles for a > particular program. There is even a note in objfiles.h about the > hazards of the basic "pointer to next" approach, which was the very > height of C fashion twenty years ago, but is actually a chronic source > of bugs and memory leaks. > I'd read this more as an argument in favour of a managed runtime environment that included features such as garbage collection. You're right that we need to re-think the way we allocate and manage memory for debug-info; determining a new global strategy for its management. Once we've figured that out we can look forward to implementing it, and we may in deed find that the mechanisms provided by C++ aid in local aspects of the global strategy (we might also find that the complexity of C++'s features actually obscure the problem :-). The thing to recognize is that C++ is a tool here, not a silver bullet.