[Mono-list] Re: debugger

[Martin Baulig]

"Daniel Morgan" <danmorg@sc.rr.com> writes:

> What do I need to do to get the debugger up and running on Linux?  What are
> the requirements?
> gtk# and gtk+ 2.0 I'm sure.  Do I need GNOME 2.0 too?

Hi Daniel,

well, for the GUI you need gtk# and GNOME 2.

However, the debugger also has a command line interface which just needs glib (but this
dependency is "weak" and could possibly be avoided).  At the moment, the makefile doesn't
allow you to build just the command line interface, but I'll probably change this for the
release.

> Can I debug various Mono class libraries with it, such as, System.Data
> classes like DataSet?

Sure you can do this.  All you need to do is to compile them with debugging support (mcs -g).

> Can it be used to debug code which uses unmanaged code via DllImport,
> internal calls, or marshalling of data?

The debugger can debug managed and unmanaged applications - and while debugging managed
applications, you can also enter interncalls and stuff like that (actually, the debugger
has an option to turn this feature on and off).

> Can I use the debugger to debug GTK# applications on Mono?
> 
> Can I use the debugger to debug QT# applications on Mono?

Well, a gtk# or a qt# application is just a managed application, so there's nothing
special about it.  The debugger can also debug multi-threaded applications (managed and
unmanaged) which could be very useful for qt# applications (I assume qt# is fully
thread-safe and qt# applications are normally using multiple threads ?).

> Can the debugger be ported to other platforms, such as, Linux/PPC,
> FreeBSD/i386, or dare I say Windows 2000?  If so, what would it take to port
> the debugger to other platforms?

We need to distinguish between hardware architectures and operating systems here.

To port the debugger to another operating system, have a look at backends/server/server.h -
this is an unmanaged API which you need to implement for that other operating system.  The
current Linux implementation is in i386-linux-ptrace.c.

To port the debugger to another hardware architecture, you also need to implement the
managed IArchitecture interface; the current i386 implementation is in
arch/ArchitectureI386.cs.  I'm currently using architecture-specific stuff in
i386-linux-ptrace.c because there's just one architecture; it may be a good idea to split
this file - all the ptrace() stuff should be the same for Linux/PPC, for instance.

It shouldn't be that difficult to port the debugger to another hardware architecture or
another Unix system - but I have no idea whether it'll be possible to port it to any
flavor of Windows.  In any case, such a port would be a huge task and much more difficult
than porting it to another Unix system.

The problem is that to debug unmanaged applications, the debugger is using the bfd and
libopcodes libraries - which have already been ported to a lot of different Unix systems.

> What features does debugger have?  How does this differ from other debuggers
> out there?

Well, it has a lot of features :-)

However, the coolest feature I added last week are per-thread breakpoints - if you're
debugging a multi-threaded application, you can tell the debugger that a particular
breakpoint should only break in a particular thread - and this works without hardware
breakpoints.

This'll be very important when debugging system libraries such as System.Data in a
multi-threaded application because the method you're currently debugging may be called
from another thread in the meantime.

> What features would you look to see added to the debugger?

At the moment, my main focus is to stabilize the whole thing and fix a few outstanding
issues.  There are two big tasks which I'd like to complete this week: getting the module
and symbol stuff back working (this is used to restart an application which keeping your
breakpoint settings) and adding support to read a core dump of a managed application.  The
latter one has "issues", but now is the best time to do it because I'm rewriting that code
anyways.

I think in near feature, I'll work a bit on the command line interface and its expression
support - at least, I'd like to add support for array variables (you can already say
"print $a.Test", but I'd like to add "print $a [5]" etc.).

-- 
Martin Baulig
martin@gnome.org
martin@ximian.com