public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* Roadmap beginnings
@ 2008-07-11 19:53 Tom Tromey
  2008-07-11 20:56 ` Jan Kratochvil
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Tom Tromey @ 2008-07-11 19:53 UTC (permalink / raw)
  To: Frysk List

I want to start discussion about the roadmap now, even before we've
resolved a few major questions.  Initially I was hoping to defer this
until we'd dug into the gdb question a bit, and settled the various
licensing issues.  However, email yesterday from Keith showed me that
these aren't independent -- some choices we make here may affect the
outcome of those other decisions.  (More on this below.)


So, what does "best C++ debugger" mean?  Naturally, I don't have a
full list.  But, I have start -- please help add to this.


The baseline is gdb doing native debugging of a C program.  I think it
doesn't make sense to do anything less than this.  This covers the
usual stuff: breakpoints, watchpoints, step, next, print.


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.)

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

* Pretty-printing of STL containers and other C++ objects.

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


Scalability appears twice on the requirements list -- scaling to large
programs and scaling to many threads.  The latter is addressed, I
think, by the non-stop debugging design already in frysk (and being
added to gdb).  I am not sure precisely what problems gdb has with the
former; however I am told there is a BFD scalability issue when moving
to multiple processes.


There are a few concerns folks have raised about what does not appear
in the goal -- for example, cross debugging, or support for multiple
languages, or remote debugging.  While I think these things aren't
directly on our wish-list, I think these sorts of things can be
addressed with good design.  We don't want to shoot ourselves in the
foot.

One possible exception here is that, AFAIK, Red Hat only cares about
ELF targets.


Connecting to a GUI is turning out to be a driver for some decisions.
I have heard some dissatisfaction expressed about MI.  There seem to
be two schools of thought: (1) use some wire protocol to separate the
GUI from the debugger, or (2) use a library.

#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.

#2 has several nice qualities, which I won't enumerate here.  In order
to behave sanely as a library, the debugger does require a nicer
kernel API than ptrace+wait; but this is being worked on already.

However, this approach does put more constraints on the licensing.  In
particular, GPLv3 would be a bad choice, as (I believe, IANAL) it
would prevent library use in Eclipse.

This in turn would impact our ability to reuse code from gdb.  I have
had my eye on a couple gdb modules as good candidates for reuse: the
macro expansion code, and perhaps the disassemblers.  (I'm not a gdb
expert; if you know of other modular, reusable bits, I'd like to hear
about them.)

Also, if #2 is a strong requirement -- if we really believe that #1 is
a non-starter -- then that would essentially rule out working on gdb.
I say this based on my belief that gdb is not a good candidate for
librarification.

This decision is not as simple as it may seem.  For example, it would
likely restrict what "intelligence" we could put in to the CLI, as (I
imagine) the library users would largely bypass the CLI in favor of
direct API access.


As I mentioned in the earlier note, we want to provide scripting
support based on Python.  From our perspective, Python is the best
choice because it is popular and generally acceptable.


I think if we achieve all of the above, we will have made a solid C++
debugger.  For it to be "best in the world" I think we will need to
raise the bar a bit.  A few ideas I've heard kicked around:

* Reverse-time debugging.  (There are some gdb patches for this.)

* "Smart" multi-process debugging, whatever that means.  The blue sky
  idea I have heard here is to be able to step into a remote procedure
  call and start debugging the other side.  (It isn't clear to me that
  the implementation effort here is worth the payoff.)

* Multi-language debugging where one of the languages is a scripting
  language.  Offhand it seems to me that this is largely a CLI issue
  -- filtering stack traces, rewriting expressions to look into
  interpreter data structures, avoiding a direct 1:1 mapping between a
  user's notation for a {break,watch}-point and the internal objects
  that this creates, etc.

  This one really has nothing to do with C++ per se.

* Some kind of systemtap integration, as Eric has asked for.  I'm
  still very unclear on what this would look like.

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

* Fix-and-continue.  (Though this appears to be something that sounds
  cooler than it actually is.)

It is kind of unfair of me to hold out the blue-sky stuff, since I
think we will have our hands full on just the essentials.  But, I
wanted to get people thinking about this a bit more.  Also, some of
these have come up repeatedly during our internal discussions.


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

Tom

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2008-07-22 20:29 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-11 19:53 Roadmap beginnings 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
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

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).