public inbox for
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <>
To: Tom Tromey <>
Cc: Frysk List <>
Subject: Re: Roadmap beginnings
Date: Fri, 11 Jul 2008 21:53:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

> * 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

  parent reply	other threads:[~2008-07-11 21:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:53 Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz [this message]
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon
2008-07-14 17:09         ` Daniel Jacobowitz
2008-07-14 17:19     ` Ian Lance Taylor
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).