[Mono-devel-list] "xml-trace" option for mono

Gonzalo Paniagua Javier gonzalo at ximian.com
Sun Apr 4 19:22:20 EDT 2004

El dom, 04-04-2004 a las 15:21, Juraj Skripsky escribió:
> Hello Paolo,
> I cooked up a patch which adds a loadable trace profiler. It's not quite
> finished as I ran into a few problems.
> The new trace profiler should offer all the feature of the current one.
> The profiler interface needs to be changed/extended to make this
> possible:
> - The callback functions for method_enter and method_leave need to
> receive not only the method signature but also parameters passed to it
> as well as the value returned. Today's tracing code uses this:
>   void mono_trace_enter_method (MonoMethod *method, char *ebp)
>   void mono_trace_leave_method (MonoMethod *method, ...)
> I could add "char *ebp" and "..." to the enter and leave function
> signature as this information might be interesting for other profilers
> too. A new flag in MonoProfileFlags (MONO_PROFILE_ENTER_LEAVE_DATA?)
> would control whether "ebp"/"..."  are filled or left "empty". The code
> in mono_arch_instrument_{prolog,epilog} would probably have to be
> adjusted for the "empty" case.
> - There are no profiling hooks yet in the exception code (but there is a
> MONO_PROFILE_EXCEPTIONS flag). Today's tracing code prints messages
> whenever an exception is thrown, caught or "finallyed" (just grep for
> "mono_jit_trace_calls != NULL"...).
> I haven't looked at the exception code too closely, so I have no idea
> whether it is difficult to add the hooks or not...
> - The mono_profiler_startup(const char *desc) function needs an
> additional parameter "MonoAssembly *assembly" so we can still have
> program-traces (i.e. "mono --trace=program ..."). Knowing the "home"
> assembly would be interesting to other profilers too.
> A gboolean return value for mono_profiler_startup would also be nice to
> be able to signal invalid profiling options in "desc".
> (btw: I modified the code of "mono_profiler_load" to strip away the
> "modulename:" before passing the options to mono_profiler_startup. This
> makes the code shorter and more simple.)
> Should I also replace the trace calls in "aot.c" (grep for
> "mono_trace_calls != NULL") with profiler hooks?
> I also tried to move the default profiler out of "profiler.c" and into a
> loadable module (called "simple" for now). It compiles fine but mono
> stops with:
>   mono: relocation error: /usr/local/lib/libmono-profiler-simple.so:
>   undefined symbol: TlsAlloc
> This looks like some sort of linking problem. Unfortunately, the world
> of autoconf/-make/libtool/... still look pretty mysterious to me. So I'm
> completely lost with this problem...
> I left the current trace code in for now. The new trace profiler takes
> the same arguments and can be started like this:
>   mono --profile=trace:T:System.String test.exe
> The attached .c files go into the profiler directory.
> What do you think?

I suggest using a GSList for keeping more than one method filter.


More information about the Mono-devel-list mailing list