Debugger Work (Was: Roadmap beginnings)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> Anyway, the trend I wanted to demonstrate: these are
Daniel> straightforward incremental additions to GDB.

Thanks for this note.

Red Hat is going to put its "best C++ debugger" efforts into gdb.

Naturally, this was not an easy decision.  There are two basic reasons
that caused us to revisit gdb.  One reason comes from Daniel's email:
our concrete wish-list is a series of deltas to gdb; of these some are
pretty easy, and some are difficult -- but intrinsically difficult,
not difficult due to some quirk of gdb.  Another reason we took
another look at gdb is the ongoing work by Code Sourcery on non-stop
debugging and multi-process debugging.

Some folks here are worried that gdb will not satisfy Red Hat's needs
in the long term.  Our plan to deal with this contingency is to
re-examine our gdb work to see how we are doing -- either at the 6
month point, or if we hit a major architectural barrier.


Our general plan is similar to what we discussed for frysk, though of
course with some changes:

* We will work on our own branch, with frequent merges from main line.
  We do intend to merge things back to the trunk, but having a branch
  will let us time that effort more easily.  Also we want to have a
  somewhat different patch review approach, so that all team members
  are involved in patch review.  (If you're curious, we'll most likely
  use a git repository for this branch.)

* We'll set up our own mailing list(s) for discussion and patch
  review.  I don't mind reusing the frysk list, but YMMV... please
  discuss.  If you don't want the frysk list, feel free to suggest a
  name for the project.

* We'll continue to discuss our roadmap and milestones in public.
  This will start in earnest once the mailing list situation is clear.

* The C++ issue.  We're still interested in having the debugger be
  implemented in C++.  However, this will probably not be the first
  thing we tackle, primarily because we need various changes that will
  be occurring on gdb CVS trunk.

* FWIW we're going to be looking into a couple other debugging-related
  projects.  In particular, in addition to Alexandre Oliva's work on
  variable tracking in GCC, we will need a sub-project to change g++
  to emit more debug info in some cases.  Also, we'll need to work on
  making gdb work with froggy (maybe on an experimental branch).

Naturally, anybody is welcome to join us in this effort.

Tom