From: Tom Tromey <firstname.lastname@example.org>
To: Daniel Jacobowitz <email@example.com>
Cc: Frysk List <firstname.lastname@example.org>
Subject: Re: Roadmap beginnings
Date: Mon, 14 Jul 2008 16:34:00 -0000 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <20080711215243.GA30836@caradoc.them.org> (Daniel Jacobowitz's message of "Fri\, 11 Jul 2008 17\:52\:43 -0400")
>>>>> "Daniel" == Daniel Jacobowitz <firstname.lastname@example.org> 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
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,
next prev parent 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
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).