Re: Changes

[Phil Muldoon <pmuldoon at redhat dot com>]

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