public inbox for
 help / color / mirror / Atom feed
From: Tom Tromey <>
To: Daniel Jacobowitz <>
Cc: Frysk List <>
Subject: Re: Roadmap beginnings
Date: Mon, 14 Jul 2008 16:34:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Daniel Jacobowitz's message of "Fri\, 11 Jul 2008 17\:52\:43 -0400")

>>>>> "Daniel" == Daniel Jacobowitz <> writes:

Thanks for your reply.

Tom> * Correct expression parsing.  (Though I am told this is extremely
Tom> difficult to impossible in the general case.)

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

:).  I'm looking around a bit to see if I can find specifics of what
is wrong.

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

Thanks in particular for your comments on the particular C++ work
items.  I think those combined form a pretty powerful argument.
There's still some unaddressed though:

* Multi-process.  I've seen some hints on the list that this is
  coming, but not enough info to really understand.  This seems like
  something that would affect many areas -- there would seem to be
  challenges from the CLI on down.

* Scalability to lots of shared libraries.  This is tied into the

Daniel> As Ian said in his talk, ELF is a wonderful format used by almost all
Daniel> of maybe 5% of programs.  If you're going to be ELF-centric, you lose
Daniel> Windows and OS X native debugging - and that's a big user base, even
Daniel> if not directly RH customers.

Yeah, that is true.  But, my understanding is that this is
nevertheless not a goal for Red Hat.  It isn't an anti-goal, either --
just a "don't care", so if it makes things simpler, we can drop

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


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

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

Dodji sent me some interesting links to totalview docs.  They do seem
to have a lot of additional core functionality -- process-group stuff
similar to what HPD specifies, the ability to evaluate C/Fortran/asm
code fragments (nice!), memory debugging (overflows, bad free calls,
etc), tracepoints.


  reply	other threads:[~2008-07-14 16:34 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
2008-07-14 16:34   ` Tom Tromey [this message]
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).