[Mono-dev] [PATCH] Mono DTrace provider

[Andreas Färber]

Here's a patch for adding DTrace USDT support to the Mono runtime.

It introduces a configure switch --enable-dtrace to turn on DTrace  
support. If configured with --enable-dtrace, Mono uses dtrace to  
generate a header in mono/utils/, and only if on Solaris, Makefile  
rules for postprocessing the object files are triggered. Four probes  
are introduced, requiring postprocessing steps for mono, libmono and  
pedump on Solaris. The MONO_GC_END() macro for the gc-end probe causes  
the postprocessing to fail on Solaris, so I've limited it to OSX for  
now.

This patch was tested on OSX ppc and i386 and on Solaris i86. It does  
not yet support OSX x86_64 because I do not have such a machine around  
to check the $host string (is it i*86-*-darwin* or something x64- 
specific?), and for inclusion in SVN it would additionally need a copy  
of the generated header file (such as attached) for systems without  
DTrace or with DTrace disabled.

Comments and suggestions welcome.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DTrace-USDT-1.diff
Type: application/octet-stream
Size: 6988 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080527/593e8090/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono-dtrace.h
Type: application/octet-stream
Size: 1419 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080527/593e8090/attachment-0001.obj 
-------------- next part --------------

Am 25.05.2008 um 22:59 schrieb Andreas F?rber:

> Hi,
>
> I've revisited the idea of a DTrace provider for Mono and managed to  
> get it working on OpenSolaris 2008.05 (dtrace 1.6) and Mac OS X  
> v10.5 (dtrace 1.2.2).
>
> On OSX, all that is required is the C header file generated by  
> `dtrace -h`.
>
> Weird hacks around libtool are only necessary on (Open)Solaris. The  
> problem with my previous attempt was that `dtrace -G` not only needs  
> read access to the object files but also modifies them! When  
> updating libmono-static.a via `ar r` after `drace -G`, everything is  
> fine and I finally see my test probe!
> The problem with this approach still is that it's a hack, because  
> the location of the .a file and of the .o files is at the discretion  
> of libtool and thus not very portable. But since it appears to be  
> limited to Solaris, we could limit such questionable build steps to  
> that platform and an explicit configuration option.
>
> Attached is my diff, with Solaris stuff disabled. Also attached is  
> the header generated on OSX and OpenSolaris.
> Note that in mono-dtrace.nv.h the #if _DTRACE_VERSION should be  
> replaced with something more sensible via regex (to avoid my  
> workaround in mini.c), same for #include <unistd.h> which I believe  
> hearing was not portable for Windows.
> <dtrace-hack3.diff><mono-dtrace.osx.h><mono-dtrace.nv.h>
>
> Am 13.01.2008 um 19:12 schrieb Miguel de Icaza:
>
>>
>>> I thought data/ would be an obvious choice for the .d file, and  
>>> chose
>>> mono/utils for the generated header and object file but the object
>>> file seems to depend on all object files with the probes, here  
>>> mini.o
>>
>> Hand written information can go into the data directory;   Source  
>> code
>> generated by a tool should be generated at compile time.
>
> The issue with that approach is the use-case of the generated  
> header: The Solaris version thereof (dtrace 1.5+?) defines  
> convenience macros for use in the source code, guarded by an #if.  
> I.e., it defines PROVIDERNAME_PROBENAME() and  
> PROVIDERNAME_PROBENAME_ENABLED() as no-op macros for non-DTrace  
> builds. In e.g. mini.c I then #include <mono/utils/mono-dtrace.h>  
> and insert the probe as MONO_TEST ();. For this to compile, the  
> header is needed on non-DTrace-aware platforms, so we'd need some  
> version of the generated file in SVN but could overwrite it on  
> platforms with dtrace available. Or we'd need either a manual header  
> file as wrapper, sync'ed with the generated one, or our own guards  
> added around each macro invocation.
>
> The general idea would be to have a new switch --enable-dtrace which  
> defaults to "no" on all platforms. If enabled, this would check for  
> the dtrace tool and set up some arch flags and an automake/C define.  
> Then, initially, I'd suggest some simple probes for performance  
> evaluation such as ves-init-begin, ves-init-end, gc-begin and gc- 
> end. Does this sound reasonable?
>
> Compare: http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html
>
> In addition to those static probes, Sun Java on Solaris also has the  
> ability to generate providers and probes dynamically from Java code.  
> I haven't looked into that yet but it might turn out highly platform- 
> specific, and if we want to add such a thing, this too should depend  
> on the suggested configure switch, to have it disabled by default.
>
> Andreas_______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list