[Mono-dev] [PATCH] Mono DTrace provider

[Zoltan Varga]

Hi,

Some comments about the patch:
- I would vote for the --enable style instead of the --disable style,
cause enabling
  things by default is known to break builds on some environments. If
things look ok,
  we can enable it later.
- I would prefer naming the probe macros something like MONO_PROBE_..., since
  MONO_GC_BEGIN () doesn't really explain their purpose.
- The makefile changes look a bit ugly. Isn't there a more sane way of
doing them
  (by instrumenting the .o files after they are generated, for example) ?
 - why is the PEDUMP_DTRACE stuff needed at all ? Why would anyone want to
   instrument pedump ?

                        Zoltan

2008/5/27 Andreas Färber <andreas.faerber at web.de>:
> 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
>
>