[Mono-list] The Mono Debugger 0.2.0 "Boston" has been released :-)
Piers Haken
piersh@friskit.com
Sun, 19 Jan 2003 13:39:20 -0800
This is a multi-part message in MIME format.
------_=_NextPart_001_01C2C003.399727BC
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
This is remarkable work, Martin. Congratulations on your first release!
Piers.
> -----Original Message-----
> From: Martin Baulig [mailto:martin@gnome.org]=20
> Sent: Sunday, January 19, 2003 11:16 AM
> To: mono-list@ximian.com
> Cc: mono-hackers@ximian.com
> Subject: [Mono-list] The Mono Debugger 0.2.0 "Boston" has=20
> been released :-)
>=20
>=20
> Hi guys !
>=20
> After almost half a year of hacking, we finally have=20
> a first public
> release of the Mono Debugger :-)
>=20
> I spent almost the whole week fixing bugs, missed most=20
> of my classes
> and stabilized and tested the whole thing on FreeBSD on=20
> Linux, but
> now finally everything looks fine ....
>=20
> * Availability
>=20
> The source code is available at
>=20
> =09
> http://primates.ximian.com/~martin/debugger/debugger-0.2.0.tar.gz
>=20
> This release depends on the not-yet-released Mono 0.19,=20
> so you should
> either wait until Monday or get the latest runtime from=20
> CVS; there are some
> important bug fixes in it.
>=20
> There is also a Mono 0.18.1 snapshot package available=20
> if you can't wait:
>=20
> =20
> http://primates.ximian.com/~martin/debugger/mono-0.18.1.tar.gz
>=20
> If you're on GNU/Linux, you can just compile everything=20
> as usual and enjoy
> the debugger ...
>=20
> Things are a bit more complicated on FreeBSD - there's=20
> a README.FreeBSD file
> in the debugger distribution which explains how this is done.
>=20
> There are also precompiled mono and binutils binaries=20
> for FreeBSD and a
> FreeBSD port:
>=20
> http://primates.ximian.com/~martin/debugger/freebsd/
>=20
> Even if you want to compile everything yourself, you=20
> should have a look at the
> makefiles in the freebsd-ports.tar.gz to see how it's done.
>=20
> * Bug reporting
>=20
> We don't have a bugzilla product yet, for the moment=20
> just send all bug reports
> to me. I really hope there aren't too many bugs left,=20
> I tested everything over
> and over again on both platforms and everything was=20
> working, so this release
> _should_ be ok.
>=20
> After this release, the debugger will stay stable and=20
> feature-frozen in CVS, so
> it's now actually an usable product.
>=20
> * Last minute comments
>=20
> My apologies for depending on a not-yet-released Mono=20
> 0.19 - Miguel will do this
> tomorrow, but I'll be too busy at the university to=20
> make a release or send an
> announcement during the week.
>=20
> I'll be reachable via email during this week, but most=20
> likely I won't have any
> time to hack until Saturday.
>=20
> Ok, after so much testing and stuff, I should now send=20
> out this announcement, the
> NFC championship game already starts in less than an hour ....
>=20
> Martin
>=20
> * * *
>=20
> Below are the release notes from the RELEASE-NOTES-0.2.0.txt=20
> file in the tarball:
>=20
> The Mono Debugger - 0.2.0 "Boston" =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This is the first public release of the Mono Debugger :-)
>=20
> About the Mono Debugger
> -----------------------
>=20
> The Mono Debugger is a graphical debugger which is written in=20
> C#. It can debug both native and managed applications and it=20
> has a graphical and a text-mode user interface.
>=20
> At the moment, the debugger only works on the i386=20
> architecture running either a Linux 2.2.x or 2.4.x kernel or=20
> FreeBSD 4.7. Most likely, the debugger also works on OpenBSD,=20
> but I don't have an OpenBSD system to test it.
>=20
> You can debug any single-threaded and multi-threaded managed=20
> applications (unmanaged multi-threaded applications are also=20
> supported, but a few restrictions apply in this case).
>=20
> Design Goals
> ------------
>=20
> The debugger was designed to be modular and portable to other=20
> systems. However, when we started this project, we were=20
> already short on time so the backend is currently only=20
> implemented on the i386 architecture running either a Linux=20
> or BSD kernel.
>=20
> Our main idea was to write a debugger for managed=20
> applications, but still being able to debug unmanaged=20
> applications such as the JIT if necessary. However, due to=20
> the limited time we had on our hands, support for unmanaged=20
> applications is still a bit preliminary; it should be enough=20
> for a hacker to fix a bug, but it's way too uncomfortable for=20
> an ordinary user.
>=20
> Unlike other debugger GUI's, the debugger does not talk to an=20
> external debugger application such as gdb, but does everything itself.
>=20
> Thanks
> ------
>=20
> First of all, I'd like to thank Ximian, Inc. which is a=20
> wonderful company to work for and Miguel de Icaza who helped=20
> me a lot this summer. Without them, this project wouldn't=20
> have become possible.
>=20
> I really appreciated hacking on this and it is a lot of fun=20
> to see my "baby" grow and develop :-)
>=20
> Limitations
> -----------
>=20
> Ok, before promising too much, let's start with the limitations ;-)
>=20
> At the moment, the debugger only works on the i386=20
> architecture. Despite its modular design, it's probably a=20
> huge task to port it to another hardware architecture.
>=20
> When we started the project, I originally wrote the backend=20
> just for Linux 2.2.x, but while doing the FreeBSD port I=20
> realized how easy it was to do this - so the debugger can=20
> probably be ported to all flavors of BSD with very little effort.
>=20
> The only limitation is that the operating system must support=20
> kernel-level threads and you must use them in glib and the=20
> runtime. This is explained a bit more detailed in README.FreeBSD.
>=20
> When debugging unmanaged applications, you cannot view any=20
> parameters or local variables. This is because the code to=20
> read the type information from a DWARF 2 symbol file is not=20
> yet written. At the moment, you need to use the HexEditor=20
> together with the method's disassembly and register viewer ......
>=20
> At the moment, you cannot modify parameters or local=20
> variables. To do this right, we need to write an expression=20
> parser, but this takes some time to implement.
>=20
> Currently we cannot store the module list and breakpoints to=20
> disk because serialization support in Mono is not yet mature enough.
>=20
> The user interface still needs some loving.
>=20
> Features
> --------
>=20
> * Single Stepping Engine
>=20
> The single stepping engine is responsible for=20
> single-stepping, stopping and continuing the target and=20
> getting notifications when the target hit a breakpoint.
>=20
> At the moment, the single stepping engine=20
> (class/SingleSteppingEngine.cs) can
>=20
> - step one machine instruction
> - step one machine instruction while stepping over method calls
> - step until the end of the current method
> - step until leaving a range of source lines (this includes stepping
> until reaching another source line)
> - step one source line
> - step one source line while stepping over method calls
> - step one source line while stepping over method calls, but only if
> the method is in a user-configurable list of modules=20
> (shared libs, dlls)
>=20
> When debugging managed applications, the single stepping=20
> engine can also
>=20
> - automatically trigger a JIT compilation of methods while=20
> single-stepping.
>=20
> This is done completely trasparently for the user, so you don't
> need to worry about JIT trampolines, not even when stepping one
> machine instruction, they'll be invisible for you like system
> calls.
>=20
> - insert a breakpoint on a method which is not yet JITed.
>=20
> - call a method in the target (but this is still very
> preliminar; due to the lacking expression parser we
> can't create the parameters yet).
>=20
> However, this is already used to call a property's getter and
> Object.ToString().
>=20
> The single stepping engine supports debugging multi-threaded=20
> applications; a stepping operation in one thread does not=20
> affect any of the other threads. This means for instance=20
> that it is safe to insert a breakpoint on a method which is=20
> called by another thread.
>=20
> * Breakpoints
>=20
> Breakpoints can be used in managed and unmanaged methods. =20
> You can insert a breakpoint either for a method or for a source line.
>=20
> When inserting the breakpoint for a method, it'll be inserted=20
> on the instruction immediately following the method's=20
> prologue. So when the breakpoint it hit, the method's=20
> parameters can already be accessed.
>=20
> Breakpoints may be inserted for not-yet-JITed methods, the=20
> debugger will automatically insert the breakpoint when the=20
> method is JITed. When inserting the breakpoints by source=20
> line, it'll also re-lookup its address each time the method=20
> is JITed. This allows the JIT to create different code for=20
> the method each time it JITs it and breakpoints will still be working.
>=20
> The user interface may supply its own breakpoint handler=20
> class which may be used to implement conditional breakpoints;=20
> such a conditional breakpoint can also read parameters and=20
> local variables to decide whether to continue the target.
>=20
> Breakpoints can be inserted on a per-thread level, this means=20
> that a breakpoint will only "break" on the "correct" thread. =20
> This is very important when debugging system functions such as corlib.
>=20
> * Modules
>=20
> Each shared library and each dll appears as a module to the=20
> debugger. The user may configure whether to enter a module's=20
> methods while single-stepping and load/unload the module's=20
> symbol tables.
>=20
> The module list persists across multiple invocations of the=20
> same target; later on we can even synchronize it to disk - as=20
> well as the user's breakpoint settings.
>=20
> * Parameters and local variables
>=20
> Type support for managed types is almost complete. The=20
> debugger can already read all fundamental types, arrays,=20
> structs and classes. It can call a property's getter method=20
> and invoke an object's ToString() method.
>=20
> * Disassembly and processor registers
>=20
> The debugger has a CPU view to see a disassembly of the=20
> current method and view/modify the processor registers. =20
> There's also a hex editor to view/modify the target's memory.
>=20
> * Hex Editor
>=20
> The debugger has a hex editor to inspect or modify the=20
> target's memory.
>=20
> * Command line interface
>=20
> In addition to the graphical user interface, the debugger=20
> also has a textual command line interface (which is also=20
> available in the GUI).
>=20
> The command line interface has a few very cool features which=20
> the GUI does not have:
>=20
> - when debugging multi-threaded applications, you can debug all
> threads, not just the main thread. This includes single-stepping,
> getting stack frames and backtraces etc. for any of the other
> threads.
>=20
> - all commands are synchronous, especially the stepping commands;
> the debugger waits until the target has stopped again.
>=20
> - you can access variables from any stack frame, not just from the
> current one.
>=20
> - there's a (still very simple) expression evaluator which allows
> you to inspect local variables and parameters.
>=20
> - it can be used as regression test suite.
>=20
>=20
> January 19th, 2003
> Martin Baulig <martin@ximian.com>
>=20
> --=20
> Martin Baulig
> martin@gnome.org
> martin@ximian.com
>=20
>=20
> _______________________________________________
> Mono-list maillist - Mono-list@ximian.com=20
> http://lists.ximian.com/mailman/listinfo/mono-list
>=20
------_=_NextPart_001_01C2C003.399727BC
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: [Mono-list] The Mono Debugger 0.2.0 "Boston" has =
been released :-)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>This is remarkable work, Martin. Congratulations on =
your first release!</FONT>
</P>
<P><FONT SIZE=3D2>Piers.</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Martin Baulig [<A =
HREF=3D"mailto:martin@gnome.org">mailto:martin@gnome.org</A>] </FONT>
<BR><FONT SIZE=3D2>> Sent: Sunday, January 19, 2003 11:16 AM</FONT>
<BR><FONT SIZE=3D2>> To: mono-list@ximian.com</FONT>
<BR><FONT SIZE=3D2>> Cc: mono-hackers@ximian.com</FONT>
<BR><FONT SIZE=3D2>> Subject: [Mono-list] The Mono Debugger 0.2.0 =
"Boston" has </FONT>
<BR><FONT SIZE=3D2>> been released :-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hi guys !</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
After almost half a year of hacking, we finally have </FONT>
<BR><FONT SIZE=3D2>> a first public</FONT>
<BR><FONT SIZE=3D2>> release of the =
Mono Debugger :-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I spent almost =
the whole week fixing bugs, missed most </FONT>
<BR><FONT SIZE=3D2>> of my classes</FONT>
<BR><FONT SIZE=3D2>> and stabilized =
and tested the whole thing on FreeBSD on </FONT>
<BR><FONT SIZE=3D2>> Linux, but</FONT>
<BR><FONT SIZE=3D2>> now finally =
everything looks fine ....</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Availability</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The source code =
is available at</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
</FONT>
<BR><FONT SIZE=3D2>> <A =
HREF=3D"http://primates.ximian.com/~martin/debugger/debugger-0.2.0.tar.gz=
">http://primates.ximian.com/~martin/debugger/debugger-0.2.0.tar.gz</A></=
FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This release =
depends on the not-yet-released Mono 0.19, </FONT>
<BR><FONT SIZE=3D2>> so you should</FONT>
<BR><FONT SIZE=3D2>> either wait until =
Monday or get the latest runtime from </FONT>
<BR><FONT SIZE=3D2>> CVS; there are some</FONT>
<BR><FONT SIZE=3D2>> important bug =
fixes in it.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> There is also a =
Mono 0.18.1 snapshot package available </FONT>
<BR><FONT SIZE=3D2>> if you can't wait:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
</FONT>
<BR><FONT SIZE=3D2>> <A =
HREF=3D"http://primates.ximian.com/~martin/debugger/mono-0.18.1.tar.gz">h=
ttp://primates.ximian.com/~martin/debugger/mono-0.18.1.tar.gz</A></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If you're on =
GNU/Linux, you can just compile everything </FONT>
<BR><FONT SIZE=3D2>> as usual and enjoy</FONT>
<BR><FONT SIZE=3D2>> the debugger =
...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Things are a bit =
more complicated on FreeBSD - there's </FONT>
<BR><FONT SIZE=3D2>> a README.FreeBSD file</FONT>
<BR><FONT SIZE=3D2>> in the debugger =
distribution which explains how this is done.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> There are also =
precompiled mono and binutils binaries </FONT>
<BR><FONT SIZE=3D2>> for FreeBSD and a</FONT>
<BR><FONT SIZE=3D2>> FreeBSD =
port:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
<A =
HREF=3D"http://primates.ximian.com/~martin/debugger/freebsd/">http://prim=
ates.ximian.com/~martin/debugger/freebsd/</A></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Even if you want =
to compile everything yourself, you </FONT>
<BR><FONT SIZE=3D2>> should have a look at the</FONT>
<BR><FONT SIZE=3D2>> makefiles in the =
freebsd-ports.tar.gz to see how it's done.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Bug reporting</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> We don't have a =
bugzilla product yet, for the moment </FONT>
<BR><FONT SIZE=3D2>> just send all bug reports</FONT>
<BR><FONT SIZE=3D2>> to me. I =
really hope there aren't too many bugs left, </FONT>
<BR><FONT SIZE=3D2>> I tested everything over</FONT>
<BR><FONT SIZE=3D2>> and over again on =
both platforms and everything was </FONT>
<BR><FONT SIZE=3D2>> working, so this release</FONT>
<BR><FONT SIZE=3D2>> _should_ be =
ok.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> After this =
release, the debugger will stay stable and </FONT>
<BR><FONT SIZE=3D2>> feature-frozen in CVS, so</FONT>
<BR><FONT SIZE=3D2>> it's now actually =
an usable product.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Last minute comments</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> My apologies for =
depending on a not-yet-released Mono </FONT>
<BR><FONT SIZE=3D2>> 0.19 - Miguel will do this</FONT>
<BR><FONT SIZE=3D2>> tomorrow, but =
I'll be too busy at the university to </FONT>
<BR><FONT SIZE=3D2>> make a release or send an</FONT>
<BR><FONT SIZE=3D2>> announcement =
during the week.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I'll be reachable =
via email during this week, but most </FONT>
<BR><FONT SIZE=3D2>> likely I won't have any</FONT>
<BR><FONT SIZE=3D2>> time to hack =
until Saturday.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Ok, after so much =
testing and stuff, I should now send </FONT>
<BR><FONT SIZE=3D2>> out this announcement, the</FONT>
<BR><FONT SIZE=3D2>> NFC championship =
game already starts in less than an hour ....</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Martin</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>> =
&=
nbsp; =
* * *</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Below are the release notes from the =
RELEASE-NOTES-0.2.0.txt </FONT>
<BR><FONT SIZE=3D2>> file in the tarball:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The Mono Debugger - 0.2.0 "Boston" =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This is the first public release of the Mono =
Debugger :-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> About the Mono Debugger</FONT>
<BR><FONT SIZE=3D2>> -----------------------</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The Mono Debugger is a graphical debugger which =
is written in </FONT>
<BR><FONT SIZE=3D2>> C#. It can debug both native and managed =
applications and it </FONT>
<BR><FONT SIZE=3D2>> has a graphical and a text-mode user =
interface.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At the moment, the debugger only works on the =
i386 </FONT>
<BR><FONT SIZE=3D2>> architecture running either a Linux 2.2.x or =
2.4.x kernel or </FONT>
<BR><FONT SIZE=3D2>> FreeBSD 4.7. Most likely, the debugger also =
works on OpenBSD, </FONT>
<BR><FONT SIZE=3D2>> but I don't have an OpenBSD system to test =
it.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> You can debug any single-threaded and =
multi-threaded managed </FONT>
<BR><FONT SIZE=3D2>> applications (unmanaged multi-threaded =
applications are also </FONT>
<BR><FONT SIZE=3D2>> supported, but a few restrictions apply in this =
case).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Design Goals</FONT>
<BR><FONT SIZE=3D2>> ------------</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The debugger was designed to be modular and =
portable to other </FONT>
<BR><FONT SIZE=3D2>> systems. However, when we started this project, =
we were </FONT>
<BR><FONT SIZE=3D2>> already short on time so the backend is =
currently only </FONT>
<BR><FONT SIZE=3D2>> implemented on the i386 architecture running =
either a Linux </FONT>
<BR><FONT SIZE=3D2>> or BSD kernel.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Our main idea was to write a debugger for =
managed </FONT>
<BR><FONT SIZE=3D2>> applications, but still being able to debug =
unmanaged </FONT>
<BR><FONT SIZE=3D2>> applications such as the JIT if necessary. =
However, due to </FONT>
<BR><FONT SIZE=3D2>> the limited time we had on our hands, support =
for unmanaged </FONT>
<BR><FONT SIZE=3D2>> applications is still a bit preliminary; it =
should be enough </FONT>
<BR><FONT SIZE=3D2>> for a hacker to fix a bug, but it's way too =
uncomfortable for </FONT>
<BR><FONT SIZE=3D2>> an ordinary user.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Unlike other debugger GUI's, the debugger does =
not talk to an </FONT>
<BR><FONT SIZE=3D2>> external debugger application such as gdb, but =
does everything itself.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thanks</FONT>
<BR><FONT SIZE=3D2>> ------</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> First of all, I'd like to thank Ximian, Inc. =
which is a </FONT>
<BR><FONT SIZE=3D2>> wonderful company to work for and Miguel de =
Icaza who helped </FONT>
<BR><FONT SIZE=3D2>> me a lot this summer. Without them, this =
project wouldn't </FONT>
<BR><FONT SIZE=3D2>> have become possible.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I really appreciated hacking on this and it is a =
lot of fun </FONT>
<BR><FONT SIZE=3D2>> to see my "baby" grow and develop =
:-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Limitations</FONT>
<BR><FONT SIZE=3D2>> -----------</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Ok, before promising too much, let's start with =
the limitations ;-)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At the moment, the debugger only works on the =
i386 </FONT>
<BR><FONT SIZE=3D2>> architecture. Despite its modular design, it's =
probably a </FONT>
<BR><FONT SIZE=3D2>> huge task to port it to another hardware =
architecture.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> When we started the project, I originally wrote =
the backend </FONT>
<BR><FONT SIZE=3D2>> just for Linux 2.2.x, but while doing the =
FreeBSD port I </FONT>
<BR><FONT SIZE=3D2>> realized how easy it was to do this - so the =
debugger can </FONT>
<BR><FONT SIZE=3D2>> probably be ported to all flavors of BSD with =
very little effort.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The only limitation is that the operating system =
must support </FONT>
<BR><FONT SIZE=3D2>> kernel-level threads and you must use them in =
glib and the </FONT>
<BR><FONT SIZE=3D2>> runtime. This is explained a bit more detailed =
in README.FreeBSD.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> When debugging unmanaged applications, you =
cannot view any </FONT>
<BR><FONT SIZE=3D2>> parameters or local variables. This is =
because the code to </FONT>
<BR><FONT SIZE=3D2>> read the type information from a DWARF 2 symbol =
file is not </FONT>
<BR><FONT SIZE=3D2>> yet written. At the moment, you need to =
use the HexEditor </FONT>
<BR><FONT SIZE=3D2>> together with the method's disassembly and =
register viewer ......</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At the moment, you cannot modify parameters or =
local </FONT>
<BR><FONT SIZE=3D2>> variables. To do this right, we need to =
write an expression </FONT>
<BR><FONT SIZE=3D2>> parser, but this takes some time to =
implement.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Currently we cannot store the module list and =
breakpoints to </FONT>
<BR><FONT SIZE=3D2>> disk because serialization support in Mono is =
not yet mature enough.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The user interface still needs some =
loving.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Features</FONT>
<BR><FONT SIZE=3D2>> --------</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Single Stepping Engine</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The single stepping engine is responsible for =
</FONT>
<BR><FONT SIZE=3D2>> single-stepping, stopping and continuing the =
target and </FONT>
<BR><FONT SIZE=3D2>> getting notifications when the target hit a =
breakpoint.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At the moment, the single stepping engine =
</FONT>
<BR><FONT SIZE=3D2>> (class/SingleSteppingEngine.cs) can</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - step one machine =
instruction</FONT>
<BR><FONT SIZE=3D2>> - step one machine instruction while =
stepping over method calls</FONT>
<BR><FONT SIZE=3D2>> - step until the end of the current =
method</FONT>
<BR><FONT SIZE=3D2>> - step until leaving a range of =
source lines (this includes stepping</FONT>
<BR><FONT SIZE=3D2>> until reaching another =
source line)</FONT>
<BR><FONT SIZE=3D2>> - step one source line</FONT>
<BR><FONT SIZE=3D2>> - step one source line while =
stepping over method calls</FONT>
<BR><FONT SIZE=3D2>> - step one source line while =
stepping over method calls, but only if</FONT>
<BR><FONT SIZE=3D2>> the method is in a =
user-configurable list of modules </FONT>
<BR><FONT SIZE=3D2>> (shared libs, dlls)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> When debugging managed applications, the single =
stepping </FONT>
<BR><FONT SIZE=3D2>> engine can also</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - automatically trigger a JIT =
compilation of methods while </FONT>
<BR><FONT SIZE=3D2>> single-stepping.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This is done completely =
trasparently for the user, so you don't</FONT>
<BR><FONT SIZE=3D2>> need to worry about JIT =
trampolines, not even when stepping one</FONT>
<BR><FONT SIZE=3D2>> machine instruction, =
they'll be invisible for you like system</FONT>
<BR><FONT SIZE=3D2>> calls.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - insert a breakpoint on a method =
which is not yet JITed.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - call a method in the target (but =
this is still very</FONT>
<BR><FONT SIZE=3D2>> preliminar; due to the =
lacking expression parser we</FONT>
<BR><FONT SIZE=3D2>> can't create the =
parameters yet).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> However, this is already =
used to call a property's getter and</FONT>
<BR><FONT SIZE=3D2>> =
Object.ToString().</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The single stepping engine supports debugging =
multi-threaded </FONT>
<BR><FONT SIZE=3D2>> applications; a stepping operation in one thread =
does not </FONT>
<BR><FONT SIZE=3D2>> affect any of the other threads. This =
means for instance </FONT>
<BR><FONT SIZE=3D2>> that it is safe to insert a breakpoint on a =
method which is </FONT>
<BR><FONT SIZE=3D2>> called by another thread.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Breakpoints</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Breakpoints can be used in managed and unmanaged =
methods. </FONT>
<BR><FONT SIZE=3D2>> You can insert a breakpoint either for a method =
or for a source line.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> When inserting the breakpoint for a method, =
it'll be inserted </FONT>
<BR><FONT SIZE=3D2>> on the instruction immediately following the =
method's </FONT>
<BR><FONT SIZE=3D2>> prologue. So when the breakpoint it hit, =
the method's </FONT>
<BR><FONT SIZE=3D2>> parameters can already be accessed.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Breakpoints may be inserted for not-yet-JITed =
methods, the </FONT>
<BR><FONT SIZE=3D2>> debugger will automatically insert the =
breakpoint when the </FONT>
<BR><FONT SIZE=3D2>> method is JITed. When inserting the breakpoints =
by source </FONT>
<BR><FONT SIZE=3D2>> line, it'll also re-lookup its address each time =
the method </FONT>
<BR><FONT SIZE=3D2>> is JITed. This allows the JIT to create =
different code for </FONT>
<BR><FONT SIZE=3D2>> the method each time it JITs it and breakpoints =
will still be working.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The user interface may supply its own breakpoint =
handler </FONT>
<BR><FONT SIZE=3D2>> class which may be used to implement conditional =
breakpoints; </FONT>
<BR><FONT SIZE=3D2>> such a conditional breakpoint can also read =
parameters and </FONT>
<BR><FONT SIZE=3D2>> local variables to decide whether to continue =
the target.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Breakpoints can be inserted on a per-thread =
level, this means </FONT>
<BR><FONT SIZE=3D2>> that a breakpoint will only "break" on =
the "correct" thread. </FONT>
<BR><FONT SIZE=3D2>> This is very important when debugging system =
functions such as corlib.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Modules</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Each shared library and each dll appears as a =
module to the </FONT>
<BR><FONT SIZE=3D2>> debugger. The user may configure whether to =
enter a module's </FONT>
<BR><FONT SIZE=3D2>> methods while single-stepping and load/unload =
the module's </FONT>
<BR><FONT SIZE=3D2>> symbol tables.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The module list persists across multiple =
invocations of the </FONT>
<BR><FONT SIZE=3D2>> same target; later on we can even synchronize it =
to disk - as </FONT>
<BR><FONT SIZE=3D2>> well as the user's breakpoint settings.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Parameters and local variables</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Type support for managed types is almost =
complete. The </FONT>
<BR><FONT SIZE=3D2>> debugger can already read all fundamental types, =
arrays, </FONT>
<BR><FONT SIZE=3D2>> structs and classes. It can call a =
property's getter method </FONT>
<BR><FONT SIZE=3D2>> and invoke an object's ToString() method.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Disassembly and processor registers</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The debugger has a CPU view to see a disassembly =
of the </FONT>
<BR><FONT SIZE=3D2>> current method and view/modify the processor =
registers. </FONT>
<BR><FONT SIZE=3D2>> There's also a hex editor to view/modify the =
target's memory.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Hex Editor</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The debugger has a hex editor to inspect or =
modify the </FONT>
<BR><FONT SIZE=3D2>> target's memory.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> * Command line interface</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> In addition to the graphical user interface, the =
debugger </FONT>
<BR><FONT SIZE=3D2>> also has a textual command line interface (which =
is also </FONT>
<BR><FONT SIZE=3D2>> available in the GUI).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> The command line interface has a few very cool =
features which </FONT>
<BR><FONT SIZE=3D2>> the GUI does not have:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - when debugging multi-threaded applications, =
you can debug all</FONT>
<BR><FONT SIZE=3D2>> threads, not just the main =
thread. This includes single-stepping,</FONT>
<BR><FONT SIZE=3D2>> getting stack frames and backtraces =
etc. for any of the other</FONT>
<BR><FONT SIZE=3D2>> threads.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - all commands are synchronous, especially the =
stepping commands;</FONT>
<BR><FONT SIZE=3D2>> the debugger waits until the target =
has stopped again.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - you can access variables from any stack frame, =
not just from the</FONT>
<BR><FONT SIZE=3D2>> current one.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - there's a (still very simple) expression =
evaluator which allows</FONT>
<BR><FONT SIZE=3D2>> you to inspect local variables and =
parameters.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> - it can be used as regression test =
suite.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> January 19th, 2003</FONT>
<BR><FONT SIZE=3D2>> Martin Baulig <martin@ximian.com></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -- </FONT>
<BR><FONT SIZE=3D2>> Martin Baulig</FONT>
<BR><FONT SIZE=3D2>> martin@gnome.org</FONT>
<BR><FONT SIZE=3D2>> martin@ximian.com</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> Mono-list maillist - =
Mono-list@ximian.com </FONT>
<BR><FONT SIZE=3D2>> <A =
HREF=3D"http://lists.ximian.com/mailman/listinfo/mono-list">http://lists.=
ximian.com/mailman/listinfo/mono-list</A></FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C2C003.399727BC--