This is the mail archive of the
mailing list for the Archer project.
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 24 Jul 2008 14:34:24 -0600
- Subject: Roadmap
- Reply-to: Tom Tromey <tromey at redhat dot com>
At the last meeting, Phil suggested that we kick off Archer with a
recap of the roadmap.
Our goal remains the same:
Build the best C++ debugger in the world.
This has a few sub-goals:
* Have a CLI
* Integrate with Eclipse
* Scale to very large programs (w/ lots of shared libraries)
* Scale to many threads
So, what does this really mean? Again from the discussion on the
* Correct C++ expression parsing. I am told this is extremely
difficult to impossible in the general case. However, we can at the
very least improve on what is currently there. Gdb's bug tracker
has some concrete information; what to do in the long term requires
* 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. I think this would
be similar to the longjmp support already in gdb.
* Pretty-printing of STL containers and other C++ objects. This is
in-progress upstream, via the Python scripting work.
* 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. This requires some GCC work.
* Multi-process. There's a recent discussion on the gdb list about
this; Stan Shebs at Code Sourcery is looking into it.
* Scalability to lots of shared libraries. This requires
investigation. Jan has looked into this a bit.
* Change gdb to use froggy, aka ntrace -- the user-space API to
utrace. Offhand, I think in the short term we should probably do
this work on an experimental branch.
* Fix various C++/debuginfo problems in GCC. A quick look at GCC
bugzilla reveals a number of things to implement.
* Investigate the various patches in the Fedora RPM. This is a
one-time thing, so more of a task, but I thought it was worth
Is there anything missing? If so, please follow up.
Meanwhile, I'll edit this into the wiki soon. We can always add to
the list later as need be.
I think the next step here is to break these down into tasks and make
a rough list of milestones. Then we can start work.