[Mono-dev] [PATCH] Mono DTrace provider
andreas.faerber at web.de
Wed May 28 10:44:32 EDT 2008
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 */
#include <mono/utils/mono-dtrace.h> /* the dtrace-generated header */
#define MONO_PROBE_GC_BEGIN(generation) MONO_GC_BEGIN(generation)
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.
More information about the Mono-devel-list