"Daniel Morgan" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
