How to use the debug support in the jit.
----------------------------------------

You need to run mono inside gdb. The following command line swicthes 
are available:

	--stabs
	--debug methodName

--stabs will create an assemblyname-stabs.s file for each assembly the
CLR program uses.  Note that to properly display source code lines,
you need to disassemble the CLR executables with monodis before running
mono. Each IL assembly file needs to have the name <assemblyname>.il.

--debug methodName will insert a breakpoin at the beginning of
methodName's code, so that control is trasnfered to the debugger as soon
as it is entered. You may use this switch multiple times.

So, suppose you use the --debug switch, or hit a segfault inside a
jitted method.  In a shell you need to compile the stab information
created with the --stabs option with the assembler:

	as assemblyname-stabs.s -o assemblyname-stabs.o

Now, inside gdb, you can load the debug information with:

	add-symbol-file assemblyname-stabs.o 0

And at this point the debugger should be able to print a correct
backtrace, you should be able to inspect method parameters and local
variables, disassemble methods and step through the code.

Note that apparently you can't unload a symbol file from gdb, so you
need to restart it if you restart the program to debug.

Name mangling.
-------------

Currently CLR methods are exposed as C functions, so, if they are not
static, their first argument will be called 'this'.
Method names are mangled in the following way: a long name is created
concatting namespace, class name and method name. '.' chars are changed
to underscaore '_'.  To allow for overloading, the address of the
MonoMethod from wich the method was created is appended to the end of
the name (i's also handy since you can use the address in gdb to inspect
the MonoMethod).