Author: martin
Date: 2006-10-23 18:34:21 -0400 (Mon, 23 Oct 2006)
New Revision: 66911
Removed:
trunk/debugger/doc/debugger-status.txt
trunk/debugger/doc/guadec-abstract.txt
trunk/debugger/doc/gui-issues.txt
Log:
Removed some old stuff.
Deleted: trunk/debugger/doc/debugger-status.txt
===================================================================
--- trunk/debugger/doc/debugger-status.txt 2006-10-23 21:58:05 UTC (rev
66910)
+++ trunk/debugger/doc/debugger-status.txt 2006-10-23 22:34:21 UTC (rev
66911)
@@ -1,180 +0,0 @@
-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.
-
Deleted: trunk/debugger/doc/guadec-abstract.txt
===================================================================
--- trunk/debugger/doc/guadec-abstract.txt 2006-10-23 21:58:05 UTC (rev
66910)
+++ trunk/debugger/doc/guadec-abstract.txt 2006-10-23 22:34:21 UTC (rev
66911)
@@ -1,32 +0,0 @@
-Title: The Mono Debugger
-
-Abstract:
-
-The Mono Debugger is a completely new debugger which is written in C#. Unlike
-other graphical debugger frontends, it is a completely new debugger and now
just
-a wrapper for an external debugger application such as gdb. While our main
focus
-was producing a debugger for .NET applications, it can also debug "normal" Unix
-applications.
-
-In this talk, I'll give an overview of the overall architecture of the
debugger,
-explain why we wrote a completely new debugger and how it interacts with Mono's
-JIT engine. Since the debugger is designed in a very modular way, it's also
easy
-to write other frontends for it or to integrate it in IDE applications.
-
-I'll also demonstrate the GUI and explain people how to debug their
applications
-with it, so this talk will be interesting both for users and for potential
-developers.
-
-At the end of the talk, I'll also explain which areas of the debugger need more
-work and where potential contributors can help with making an even better
-super-kick-ass application.
-
-Biography:
-
-Martin is a student of applied mathematics and computer science in Germany. He
-became involved with GNOME and Free Software since the early days of this
project.
-After taking a longer leave to concentrate on university, he quickly became
involved
-with the Mono project and finally became employed by this wonderful and great
company
-Ximian where he's now hacking on Mono and the Mono Debugger as much as his
student
-live permits.
-
Deleted: trunk/debugger/doc/gui-issues.txt
===================================================================
--- trunk/debugger/doc/gui-issues.txt 2006-10-23 21:58:05 UTC (rev 66910)
+++ trunk/debugger/doc/gui-issues.txt 2006-10-23 22:34:21 UTC (rev 66911)
@@ -1,199 +0,0 @@
-There are some important threading issues to consider when writing a
-GUI for the debugger. This especially applies to making the debugger
-an out-of-proc component.
-
-The biggest challenge is finding the correct place to put the process
-boundary.
-
-At the moment, the debugger consists of two parts: a frontend and a
-backend which both live in two different application domains.
-
-The Backend:
-------------
-
-The backend is basically everything in the Mono.Debugger.Backends
-namespace - its most important classes are
-
- ThreadManager
- DebuggerServant
- ThreadServant
- SingleSteppingEngine (derives from ThreadServant)
-
-it is in a separate application domain so we can easily unload
-assemblies and symbol tables.
-
-One important thing to keep in mind when embedding the debugger in
-another application is that your are not allowed to use any of fork()
-or wait() in the same process where the backend lives.
-
-Regarding stability, the backend is the only "critical" part of the
-debugger.
-
-The Frontend:
--------------
-
-The frontend is basically everything in the Mono.Debugger and the
-Mono.Debugger.Frontend namespaces - its most important classes are
-
- Interpreter
- Debugger
- Thread
-
-The main job of the frontend is basically communicating with the
-backend and providing a high-level user interfaces.
-
-The frontend contains code which blocks on events from the backend,
-but there is nothing which could potentially crash a bigger
-application like MonoDevelop and there are also no constraints
-regarding fork() and wait().
-
-So in theory, it should be safe to have the frontend in the same
-process than MonoDevelop.
-
-Commands in the `Thread' class:
--------------------------------
-
-Most of the functions in the frontend are async - for instance,
-stepping operations look like this:
-
- // <summary>
- // Step one source line.
- // </summary>
- public CommandResult StepLine ()
- {
- lock (this) {
- check_servant ();
- operation_completed_event.Reset ();
- CommandResult result = new StepCommandResult (this);
- servant.StepLine (result);
- return result;
- }
- }
-
-Here, `servant.StepLine (result)' just starts the operation (or throws
-an exception if something goes wrong, for instance no target), but
-does not block. These commands return a `CommandResult' which you can
-Wait() on.
-
-When doing this out-of-proc, the only thing we probably need to keep
-in mind is that the `servant' might be dead, not responding etc. - but
-in general, this should be ok.
-
-Some commands return a result:
-
- public override AssemblerLine DisassembleInstruction (Method method,
TargetAddress address)
- {
- check_servant ();
- return servant.DisassembleInstruction (method, address);
- }
-
-These need to go through the debugger's main loop, but they should
-never block. Going through the debugger's main loop is, however, an
-expensive operation, so it might be unacceptable to use them directly
-from a GUI thread - we have to check.
-
-When out-of-proc, the `servant' could also be dead, not responding or
-crash during that call, so remoting should detect that somehow.
-
-Some commands block on the target:
-
- public TargetObject RuntimeInvoke (TargetFunctionType function,
- TargetClassObject object_argument,
- TargetObject[] param_objects,
- bool is_virtual, out string
exc_message)
- {
- CommandResult result;
-
- lock (this) {
- check_servant ();
- result = servant.RuntimeInvoke (
- function, object_argument, param_objects,
is_virtual, false);
- }
-
- result.Wait ();
-
- RuntimeInvokeResult res = (RuntimeInvokeResult) result.Result;
- if (res == null) {
- exc_message = null;
- return null;
- }
- exc_message = res.ExceptionMessage;
- return res.ReturnObject;
- }
-
-This command may take a very long time to complete ....
-
-Callbacks from the backend:
----------------------------
-
-Sometimes, the backend must send some event to the frontend. This may
-cause some problems when out-of-proc.
-
-At the moment, it basically works like this.
-
-On the sending side in the backend - in `DebuggerServant':
-
- internal void SendTargetEvent (SingleSteppingEngine sse,
TargetEventArgs args)
- {
- try {
- if (sse.Thread.IsDaemon &&
- ((args.Type == TargetEventType.TargetExited) ||
- (args.Type == TargetEventType.TargetSignaled)))
- return;
- client.OnTargetEvent (sse.Thread, args);
- } catch (Exception ex) {
- Error ("{0} caught exception while sending {1}:\n{2}",
- sse, args, ex);
- }
- }
-
-Here, 'client' is an instance of `Debugger' and `sse.Thread' an
-instance of `Thread'.
-
-On the receiving side in the frontend - in `Debugger':
-
- internal void OnTargetEvent (Thread thread, TargetEventArgs args)
- {
- if (TargetEvent != null)
- TargetEvent (thread, args);
- }
-
-The `TargetEventArgs args' is serializable - no problem with that.
-
-Note that there is a big problem if the frontend uses the `thread'
-argument to call back into the backend and we're out-of-proc:
-
-At the moment, we're just in another appdomain, so the call stays in
-the same thread and we can easily call back.
-
-However, when out-of-proc, remoting would process such a call in
-another thread - and when in another thread, we need to go through the
-debugger's main loop and dead-lock forever.
-
-In detail - it works like this:
-
-* the debugger's main loop - which is running in the engine thread -
- calls DebuggerServant.SendTargetEvent().
-* that function launches a remote call to Debugger.OnTargetEvent() -
- which is in another process and waits for its completion.
-* when the other process calls back into the SingleSteppingEngine,
- remoting processes the request in another thread.
-* the SingleSteppingEngine can only handle the request from inside the
- engine thread, so it has to go through the main loop.
-* the main loop is currently blocking on Debugger.OnTargetEvent() to
- return, so the request would fail.
-
-Making the event async is not really an option - the event handler
-normally needs to call a lot of stuff on the `thread' - ie. get stack
-traces, disassemble code, get locals etc.
-
-Going through the main-loop each time would be very slow - so I think
-what we need to do is using some kind of a serializable delegate which
-runs inside the backend's process and gathers all the required
-information before passing them to the frontend's process.
-
-So we need to make some API changes here.
-
-
-Last changed June 13th, 2006
-Martin Baulig <[EMAIL PROTECTED]>
_______________________________________________
Mono-patches maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-patches
