[Mono-dev] [PATCH] Mono DTrace provider

[Andreas Färber]

Hi Zoltan,

Thanks for the comments,

Am 28.05.2008 um 15:32 schrieb Zoltan Varga:

> - I would prefer naming the probe macros something like  
> MONO_PROBE_..., since
>  MONO_GC_BEGIN () doesn't really explain their purpose.

The PROVIDERNAME_PROBENAME[_ENABLED] scheme cannot be changed. But we  
could add a custom wrapper header, doing something like

/* mono/utils/dtrace.h */
#ifdef DTRACE_ENABLED
#include <mono/utils/mono-dtrace.h> /* the dtrace-generated header */
#define MONO_PROBE_GC_BEGIN(generation) MONO_GC_BEGIN(generation)
#else
#define MONO_PROBE_GC_BEGIN(generation)
#endif

effectively allowing us to use MONO_PROBE_... in Mono's code. As a  
side effect, this would also avoid the need to commit some version of  
the generated header to SVN for non-DTrace platforms.


> - 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) ?

I fully agree. Not sure what you mean by instrumenting them. I see two  
way of improvements:

a) Provide a shell script, as suggested in my response to Miguel, say  
dtrace-prelink.sh, which accepts as command line arguments the  
output .o file name and the input .d and .la or .lo files. This would  
hide the logic in a central place, avoiding to duplicate it in lots of  
Makefile.am files (as seen with pedump). The tool should then extract  
the .a libraries to a temporary directory, like libtool does, provide  
all object files as input to dtrace -G, whether they use probes or  
not, and update the .a archives with them.

b) Try to extend libtool to handle this step itself, reusing its  
helper functions and variables. This would theoretically be best, but  
I do not know if doable.
Also, I noticed you added support for some libtool alternative, right?  
Could you please shed some light on that in terms of where that is  
being used or what it's intended for?

> - why is the PEDUMP_DTRACE stuff needed at all ? Why would anyone  
> want to
>   instrument pedump ?

As mentioned in my other mail, this is necessary (on Solaris) to avoid  
link failure, even if not instrumented at all:

libruntime[-static].la is being linked into pedump. libruntime[- 
static].la contains boehm-gc.o and thus a probe. Therefore boehm-gc.o  
must be postprocessed specifically for pedump and the modified as well  
as the generated object file linked into pedump.

In practice, with only the gc-begin probe compiled in on Solaris  
currently, this means that executing "mono/metadata/pedump" with  
dtrace finds one probe in it. I haven't checked whether it gets  
strip'ed out during install, but I doubt pedump actually uses the GC.

Unfortunately, the object files don't get recompiled for each  
executable, so we can't use #ifdef to disable probes for pedump builds  
to avoid this step. If you see another way to avoid this, please say  
so. I tried to keep the patch least intrusive as possible, so I did  
not look into splitting up libruntime or the like.

Andreas