[Mono-dev] [PATCH] Mono DTrace provider
Miguel de Icaza
miguel at novell.com
Tue May 27 11:24:30 EDT 2008
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.
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
> 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.
> 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
More information about the Mono-devel-list