Announcing PathDB

[Bakul Shah]

[Added -hackers as this may be of some interest to others.
Hope you don't mind]

On Sun, 30 May 2010 01:27:12 +0700 =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= <cbergstrom at pathscale.com>  wrote:

> ps.  Tell me what you need to make it interesting and we'll try to make 
> it happen..

Ok, here are some "interesting" ideas!

* Add a ups like interface and I will be very happy!
    http://ups.sourceforce.net/

  Supposedly the following is needed to make it work on Linux.

    cvs -d:pserver:anonymous at ups.cvs.sourceforge.net:/cvsroot/ups login 
    cvs -z3 -d:pserver:anonymous at ups.cvs.sourceforge.net:/cvsroot/ups co -P ups
    cd ups
    ./configure --enable-longlong

  I haven't tried this on linux but with a couple of patches
  it builds and runs fine on freebsd-i386.

  It has a built in C interpreter which is very handy; you
  can add C code at breakpoints for conditional bkpts or
  patch a variable etc.

  But the GUI is the best part  -- I won't try explaining it,
  you have to experience it! Perhaps it can be used somehow?

* multi-{thread,core,process,program,machine} debugging. A
  GUI can be very useful here as you can show state of each
  thread in a separate window, pop open a new window as
  threads or processes get created etc. Basically debugging
  distributed programming support!

* A debugger language like say plan9 Acid's. With it for
  instance you can implement code coverage. See section 15
  http://www.vitanuova.com/inferno/papers/acidpaper.html for
  the code coverage trick.  Google "debugging with acid" to
  see more stuff. ups's c interpreter can be considered a
  debugger language. There is a good paper on a dataflow
  language for debugging from Brown U.
    http://www.cs.brown.edu/~sk/Publications/Papers/Published/mcskr-dataflow-lang-script-debug-journal/

* Better integration with testing. There are IDEs that
  integrate debugging with code development but I am not
  aware of any that integrates it well with testing. Testing
  is still a batch process. When a test fails, I want to dive
  right in, figure out what went wrong, fix it and rerun or
  continue! I admit I have the vaguest idea of even what this
  means.  The dataflow lang paper refed may be relevant as it
  talks about automatic assertion checking etc.

* There is a lot that can be done to improve debugging GUIs.
  For instance I'd love to see 3D use. Not for eye-candy but
  for better visualization. Things like as you zoom in, you
  see more details (zoom in on a function name and "enter"
  function body -- very Fantastic Voyage-ish (1966 movie) but
  for code!), control flow shows up as color change, the more
  a code path is visited the more it lights up or gets
  fatter, IPC is shown as a flash from one thread to another
  and so on. IIRC I have seen the color change idea in some
  verilog code coverage tools.

-- bakul