2002-03-29 Martin Baulig <martin@gnome.org>

	* doc/jit-debug, docs/jit-debug-sample, docs/jit-debug-sample2:
	New files, added documentation for the debugging code.

	* doc/web/commands: Added the debugging pages.

	* docs/jit-debug: Removed, this is now on the web site.

svn path=/trunk/mono/; revision=3493

1 files changed, 0 insertions, 73 deletions

diff --git a/docs/jit-debug b/docs/jit-debug
deleted file mode 100644
index a895a6fbdff..00000000000
--- a/docs/jit-debug
+++ /dev/null
@@ -1,73 +0,0 @@
-How to use the debug support in the jit.
-----------------------------------------
-
-You need to run mono inside gdb. The following command line swicthes 
-are available:
-
-	--stabs
-	--dwarf
-	--debug className: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.
-
---dwarf will create an assemblyname-dwarf.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 className: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/dwarf information
-created with the --stabs or --dwarf option with the assembler:
-
-	as assemblyname-stabs.s -o assemblyname-stabs.o
-
-or
-
-	as assemblyname-dwarf.s -o assemblyname-dwarf.o
-
-Now, inside gdb, you can load the debug information with:
-
-	add-symbol-file assemblyname-stabs.o 0
-
-or
-
-	add-symbol-file assemblyname-dwarf.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.
-
-Using the DWARF 2 debugging format (with the --dwarf) argument is the
-recommended one since it supports source files with more than 65.536
-lines (for instance corlib.il) and you'll also get much better type
-support with it. [FIXME: I'm still working on this, but it's already
-making good progress. Martin].
-
-However, some systems or debuggers may not support the DWARF 2 format,
-in this case just use stabs.
-
-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).
-
-[This will change with DWARF 2 since this format is capable of storing
- the full type name as it's seen by the programming language and doesn't
- need any mangling. Martin]