Re: Roadmap beginnings

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jul 11, 2008 at 01:53:28PM -0600, Tom Tromey wrote:
> So, what does "best C++ debugger" mean?  Naturally, I don't have a
> full list.  But, I have start -- please help add to this.

Thanks for posting this - I think it's an enlightening question.
Let me categorize these briefly:

> There's a bunch of specific C++-debugging things that, afaik, gdb does
> not do very well:
> 
> * Correct expression parsing.  (Though I am told this is extremely
>   difficult to impossible in the general case.)

It does a not half bad job, and specific problems with it are fixable.
As for ultimate correctness and completeness, I have serious doubts
that it is feasible - and I also doubt it would see enough use to
justify the enormous investment.  Prove me wrong and we'll merge it :-)

> * Nice user experience when debugging with exceptions.  E.g., if you
>   'next' over a function call, and the function throws an exception to
>   a "higher" frame, the program should stop there.

I'd call this a small project; only weeks of work to fix.

> * Pretty-printing of STL containers and other C++ objects.

This is a bigger project, but as Tom certainly knows GDB is solving it
already.

> * Smarter demangling of names.  The ideal would be that demangling
>   yields the name that the user wrote in the source -- meaning,
>   compressing the output by omitting default arguments, and respecting
>   typedefs.

Small, maybe midsized GDB project; dependent on a larger project in
the compiler to generate useful information.  This is a recurring
theme; GCC's symbolic debug info is not adequate.

Anyway, the trend I wanted to demonstrate: these are straightforward
incremental additions to GDB.  I'll sit back now and see what else
comes up in the discussion, and if any of it has a fundamentally
different character.  I'm not convinced that it will or that it won't.

> One possible exception here is that, AFAIK, Red Hat only cares about
> ELF targets.

As Ian said in his talk, ELF is a wonderful format used by almost all
of maybe 5% of programs.  If you're going to be ELF-centric, you lose
Windows and OS X native debugging - and that's a big user base, even
if not directly RH customers.  So (stating the obvious here, I know)
keep some kind of abstraction layer on file formats, even if it makes
other things look like ELF :-)

> #1 is pretty much understood, I think.  Setting aside specific
> complaints about MI, a possible drawback I have heard is that this
> increases latency for debugging operations.  I haven't seen any
> measurements of this, though.

There is a lot of room to optimize the existing performance of GDB/MI
(and other GUI-reaction-time sensitive areas of GDB), plus the
protocol is generally pipelining-friendly.  Without numbers, I find
this hard to credit.

I've seen people hold CDT up as an example of this problem.  I'm not
personally involved with Eclipse development, but my understanding
from others is that CDT is slow because CDT is slow, not because MI is
slow.  DSF is expected to be much faster.

> * The ability to debug a program being run under valgrind.  This is
>   mildly related to the debugging-a-scripting-language question, but
>   also (I imagine) probably requires changes on the valgrind end.

I think it has little or nothing to do with the debugger; the easiest
implementation would be a remote protocol implementation in valgrind.

> It would also be worth doing a bit of competitive analysis of the
> leading closed-source debuggers out there.

I haven't done this, but my expectation is that more of the
differentiation is in the GUI capabilities than the back end
capabilities.  If you want to talk about a modern, open-source, widely
developer accessible debugger, I think you need to consider GDB +
Eclipse as a combination, not GDB alone.  You can argue about what
goes after the plus sign.

-- 
Daniel Jacobowitz
CodeSourcery