[Mono-dev] [PATCH] Mono DTrace provider

Tue May 27 11:24:30 EDT 2008

Hello,

    I do not have an opinion on the actual changes to the code, that
should be discussed by someone else, but I believe that we should
auto-detect whether dtrace is installed instead of forcing people to
manually enable it on platforms that support it.

Miguel.

On Tue, 2008-05-27 at 00:45 +0200, Andreas Färber wrote:
> 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
> 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
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list