Re: Roadmap beginnings

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.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
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
  above.

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
non-ELF.

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.

Thanks.

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.

Tom