From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22063 invoked by alias); 11 Jul 2008 10:44:42 -0000 Received: (qmail 22054 invoked by uid 22791); 11 Jul 2008 10:44:41 -0000 X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS 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 10:44:23 +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 m6BAiL64020521 for ; Fri, 11 Jul 2008 06:44:21 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BAiLVK032007; Fri, 11 Jul 2008 06:44:21 -0400 Received: from localhost.localdomain (vpn-6-2.fab.redhat.com [10.33.6.2]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BAiKjb018256; Fri, 11 Jul 2008 06:44:20 -0400 Message-ID: <48773983.5050508@redhat.com> Date: Fri, 11 Jul 2008 10:44:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: tromey@redhat.com CC: Frysk List Subject: Re: Changes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00020.txt.bz2 Tom Tromey wrote: > * GDB. A recurring question is: why not expend our efforts improving > gdb? There are no easy answers here; the tradeoffs are complicated. > > This is probably more of a Red Hat internal decision (it is about > where we want to focus our efforts, not about the frysk project per > se) -- but it is an obvious and important question and deserves to > be brought up here. > > We're open to arguments either way on this topic. Given our goals, > what would you choose to do My 2 euros on why a new project is a viable. GDB is a cool project. No doubt. It has remained relevant for years, and still does today. It has maintained the status as the best open-source debugger - free as in beer and speech through that time. And despite many pretenders and competitors it continues to remain as the best and most viable. It attracts the brightest minds, and generates sometime intense controversy; it has been described as a work of art and, well, other things not so nicely put. GDB is great because of ALL the people that work on it, past and present. How many visionaries, engineers, testers and documenters have poured effort into it over the years? Often silently, sometimes not ;) But despite this sum effort, and the momentum, I still think there is room for a new project. Because I seem them as complimentary. I do not subscribe to the division-of-labour and mutual-exclusion theories in free software. Granted, in an ideal world we should all work on one piece of software, to fulfil one concrete goal. But we do not do that, it seems. It is clearly evident through many projects: GNOME and KDE, Emacs and VIM, Eclipse and Netbeans, and so on. I find this compelling behaviour; look at the multitude of window managers that one can use with the desktop. And what we lose in division-of-labour, we gain in a a more vibrant community. But this is a deeper problem for debuggers, I think. Software is a complex. Debuggers perhaps among the most complex and challenging to write. Nobody wants a buggy debugger: the engineer who has reached for it is already frustrated. We do not need to add to the sum of that. And heaven help us if we further erode the stability of the inferior beyond the state it was in when we were called. We need more people in the open-source debugging world. So with that being said, I do not think the "new debugger" and GDB should exist in a vacuum. And as long as the licenses are compatible (and I see no reason why they should not be), we should borrow, fix, back-port and submit patches from each others software. GDB does not do C++ well. I do not like being negative, but it just doesn't. I am not terribly sure why, though I have tried to find out. Maybe the problem is that it has been added over time, to an engine that in not OOP aware? How do we solve that? I think we solve it by writing another scriptable debugger in a research like environment. Once we figure out why, there is no reason why we can then present the case to the GDB community. And similarly, GDB has a very powerful urge to remain as stable as possible. Stability over change. I do not think it is cost-efficient to be answering research question in a release environment, or in a product that has a powerful and strong promise of stability to a community. On that note, I would invite the GDB people to use this new promise of a project as a proving ground for technology. Mature it here, then port it. If we do our homework right, we can make cross-pollination as easy (or as hard, if we are sloppy) as possible. Regards Phil Muldoon