This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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
frysk list:

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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]