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

[Paolo Molaro]

On 04/04/04 Juraj Skripsky wrote:
> I cooked up a patch which adds a loadable trace profiler. It's not quite
> finished as I ran into a few problems.

Thanks (and sorry for the late review).

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

I would add a different set of callbacks if tracing is needed.
See the other mail today for background, but basically: using ebp is not
portable, so we need to have an arch-specific function which presents
the info in an arch-independent way to the callback (so, not a single
ebp arg, but an array of pointers to the arguments). since this requires
more work, I prefer to keep the profiler case faster and have a
different set of callbacks for tracing.
This way, the code to get the argument values would be completely
arch-indep e tweaking it to emit the values as xml should be very easy.

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

It should be trivial to add, the only issue here is to do the same work
in all the arch-specific files. Eventually we should try to share more
of the code in exceptions-ARCH.c.

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

There is already a way to retrive this: domain->entry_assembly (we might
want to export a function to access it).

> A gboolean return value for mono_profiler_startup would also be nice to
> be able to signal invalid profiling options in "desc".

Yes, this makes sense.

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

Well, my idea is that the same library could be used for more than one
profiler, though the same effect could be achieved anyway with profiler
options. I guess.

> Should I also replace the trace calls in "aot.c" (grep for
> "mono_trace_calls != NULL") with profiler hooks?

I didn't find them: could you elaborate?

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

The win32 calls like TlsAlloc() are not exported from libmono: they are
an internal implementation detail, so if the code is moved outside, it
should be changed to use TlsAlloc() on windows and the pthread
equivalents elsewhere (or, when possible, __thread vars).

> The attached .c files go into the profiler directory.

> Index: metadata/profiler-private.h
> ===================================================================
> RCS file: /cvs/public/mono/mono/metadata/profiler-private.h,v
> retrieving revision 1.6
> diff -u -r1.6 profiler-private.h
> --- metadata/profiler-private.h	17 Jun 2003 14:16:04 -0000	1.6
> +++ metadata/profiler-private.h	4 Apr 2004 11:06:36 -0000
> @@ -23,6 +23,7 @@
>  
>  void mono_profiler_shutdown        (void);
>  
> +gboolean mono_profiler_method_filter (MonoMethod *method);

There is no need for a filter-specific callback. a profiler that wants
to do filtering should register for the jit start event and if the
method matches its filters, change the profiling flags accordingly
(for example, set the enter/leave flag or the trace flag or clear them).

Thanks!

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better