| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 |
- 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).
|