[Mono-list] Question on Unmanaged code Invocation

[Jonathan Pryor]

On Fri, 2005-10-14 at 20:50 -0700, Shankari wrote:
> I have some questions in unmanaged call internals.
> From what I understood, an unmanaged code is a
> function call.

<pedantic>
Unmanaged code can be anything (including Perl code), and can be an
unmanaged *function*.  A function call would invoke the function.
</pedantic>

> To figure out where exactly the switch from managed to
> unmanaged code is happening, I set a breakpoint in my
> C program and tried a backtrace from it. Here is the
> info I got.
> 
> (gdb) backtrace
> #0  printmsg () at cprog.c:13
> #1  0x0045b6ac in ?? ()
> #2  0x00000001 in ?? ()
> #3  0x00e65710 in ?? ()
> #4  0x00450ad7 in ?? ()
> #5  0x093458e0 in ?? ()
> #6  0x093458c8 in ?? ()
> #7  0x09389398 in ?? ()
> #8  0x0002be60 in ?? ()
> #9  0x00000000 in ?? ()
> (gdb) n
> 0x0045b6ac in ?? ()
> (gdb) 

Translation of all that: Mono created a new thread which contains JITed
code, so no debug symbols exist (that GDB knows about).

Consequently, you need the managed callstack, which you can get using
mono_print_method_from_ip, which takes a stack pointer as an argument,
e.g.:

	(gdb) p mono_print_method_from_ip (0x0045b6ac)

> I am not able to single step through the code from the
> point where unmanaged code is ending.

That's because no source code exists for those functions, at least as
far as GDB is concerned.

> Since the backtrace addr are not resolved, it looks
> like an unmanaged call is spawned in a new thread.

Correct.  Mono creates several threads during startup for myriad reasons
(such as for the garbage collector, finalizer thread, etc.).

 - Jon