Debugger Status Report as of January 6th, 2003
==============================================

Currently, the debugger can do everything which is mentioned in the
RELEASE-NOTES-0.2.0.txt.

Current status as of 01/06/03:
------------------------------

* We're now in feature-freeze; anything which is not already implemented won't make it
  into the release.  The main focus is now to make the debugger stable and mature enough
  to be usable by a large number of people.

* I'm really happy with the command line interface; it already seems to be very stable and
  reliable.  It also has a lot of features which aren't implemented in the GUI yet.

* The command line interface has a command to insert a breakpoint on a method, but for
  managed methods, this must be the full method name including the full signature (such as
  "Martin.Baulig.Foo(int,long)").  There should be an easier way to do this.

* The command line interface has a command to insert a breakpoint on a file / line, but
  there are problems if that file is not in the current directory; we need to add a search
  path or something like this.

* There's a minor issue with core files, especially with core files from managed applications:
  The .ctor in CoreFile checks whether the core file actually belongs to the application
  you're debugging, but this check sometimes fails, especially if you're using relative
  path names.

* I've started to create a regression test suite in the tests/ directory; we should put
  more tests there.


How you can help with the debugger:
-----------------------------------

If someone wants to help with the debugger, here are a few things you could do:

* What I need most are bug reports and people who're testing the debugger.  I'd especially
  appreciate it if someone could try debugging large applications such as mcs with the
  command line interface and report any problems to bugzilla (this'd be a bug in the
  backend, so use the `backends' component for it).  You should try everything you'd
  normally do with a debugger: single-step, insert breakpoints, inspect variables etc.

  If everything works, do the same with the GUI; if possible, first try to run exactly the
  same debugging session as you did in the command line interface, but enter the commands
  in the GUI's command entry widget.  The debugger should display things graphically in
  the GUI while doing this.  If something wents wrong, this is a bug in the GUI and should
  go into the `gui' component.  If everything works fine, do the same debugging session
  again, but only use GUI commands this time.

* We need more tests in the test suite; there's a sample in tests/TestManagedTypes.cmd, but
  this one needs to be finished.  We should also have tests for the single stepping engine
  there; to do this, use the `assert line' command in the command file.

These two things should be really easy and could also be done by users or newbies.  If
you'd like to hack, here are a few things you could do:

* The feature-freeze doesn't apply to the command line interface (the frontends/scripting
  directory).  I don't have any time to hack on this myself before the release, so I won't
  accept any feature requests.  However, this whole code is really easy to understand and
  very straightforward so patches and people who'd like to hack on this would be very
  welcome :-)


Variables and types in managed code:
------------------------------------

* We don't have a GUI to display the locals and parameters of another stack frame.  If you
  look at frontends/gui/VariableDisplay.cs, it's already done for the current stack frame
  there.  Just replace `current_frame' with whatever frame you want (use
  DebuggerBackend.GetBacktrace() to get a backtrace).

  [update 01/06/03: this is implemented in the command line interface.]

* We can't access register variables from another stack frame yet.  Paolo mentioned that
  they'll be saved on the stack when doing method calls, so we can unwind the stack to get
  them.   For the current stack frame, we can just read the registers.

  [update 01/06/03: this is now implemented, but I haven't done much testing yet.]

* We can't access register variables which are stored in two registers (for instance a
  long which is in %eax and %edx).  Look at backends/mono-csharp/MonoRegisterLocation.cs,
  it should work in a similar way.

  [update 01/06/03: this is a bug, but if it turns out to be too hard to fix, we should
                    disable register variables for the moment.]

* We can't invoke methods on structs, only on classes.  When invoking a method on a
  struct, we need to box the `this' argument which isn't implemented yet.  The code is in
  MonoStructType.Invoke in backends/mono-csharp/MonoStructType.cs.

  [update 01/06/03: this is a bug and not too hard to implement; it is required to access
                    properties in a struct.]

* We can only invoke methods without arguments.  The code to call a method is
  IInferior.CallInvokeMethod() and it's also called from MonoStructType.Invoke(); what
  needs to be done is creating a `MonoObject *' for each parameter (in the target) and
  provide the addresses of these objects instead of the `new TargetAddress [0]'.

  The problem here is that we need to create an object in the target, so we need to write
  some code which evaluates a user supplied expression and creates an object instance for
  it.

  [update 01/06/03: wishlist item; won't make it into the release.]

* Also in MonoStructType.Invoke(), we should do something reasonable with the returned
  exception; at the moment, it is returned instead of the method's return value.

  [update 01/06/03: this is an API issue which must be addressed for the 0.2.0 release.]

* There is no GUI to call a properties getter or an object's ToString(); see
  frontends/command-line/Interpreter.cs for an example.

  [update 01/06/03: it'll take 5 minutes to implement this in the command-line interface,
                    so this'll make it into the release.]

JIT issues:
-----------

* The lifetime information for local variables is sometimes wrong: for the debugger, a
  variable's lifetime starts _after_ it has been assigned, but the JIT need to create the
  variable _before_ it can assign it a value.

* We currently assumes that a variable's lifetime is continuous, ie. that it last from
  code position X until code position Y.  This is not always correct; sometimes the JIT
  creates two or more entries in MonoFlowGraph.locals for the same variable.

* In jit.c we should always set t->cli_addr, add it as argument to PUSH_TREE(); Dietmar
  should know what to do.

* We should write a small tool to write a symbol file for an arbitrary assembly to debug
  its IL code.  This tool should create both the IL file and the symbol file and use the
  IL file as `source code'.

  [update 01/06/03: wishlist item; won't make it into the release.]

Single stepping issues:
-----------------------

* There is no command to make the current stack frame return.

  [update 01/06/03: sounds like a cool and useful feature, but it is too much work to get
                    it right, so it won't make it into the release.]

Modules:
--------

* We should allow the user to add modules; for instance if the user knows that the
  application will at some point dynamically open a shared library or assembly, it should be
  possible to set a breakpoint in this module.  Currently, you need to wait until the
  debugger loaded the module before you can insert the breakpoint.  However, the
  breakpoint will be automatically inserted when restarting the target.

  [update 01/06/03: wishlist item; won't make it into the release.]

* Currently, we're getting a notification when the target loads a new shared library.  We
  should do the same for managed applications, ie. let the JIT call a special method each
  time it opened a new assembly so that we could insert a breakpoint on that method.

  [update 01/06/03: wishlist item; won't make it into the release.]

* When inserting a breakpoint for a not-yet-JITed method, the debugger invokes a special
  function in the target's JIT to get a breakpoint when that method gets JITed.  This
  method takes an arbitrary method name which does not need to exist - so we should also
  add a GUI item to insert such an arbitrary breakpoint.

  The same applies for native libraries: we could have a list of such breakpoints and each
  time a new shared library gets loaded, we scan its symbol file to find out whether it
  has a method with that name.

  [update 01/06/03: this is important and must go into the release; the whole breakpoint stuff
                    is useless if the user interface has no command to insert a breakpoint.]

General:
--------

* This file should go away, we should use bugzilla to keep track of bugs and outstanding
  tasks, but there's no bugzilla product for the debugger yet.

