On Fri, Jun 12, 2009 at 09:52:22AM -0700, Neale Ferguson wrote:
> I am in the process of porting dtrace to OpenSolaris on System z. I
> am looking in dt_link.c trying to understand dt_modtext(). There are
> separate implementations for each supported architecture. It appears to
> look for particular call sequences and either "no-op" them or place
> return sequences in there. What particular calls is it replacing and
> what do the instruction sequences look like before and after
> replacement?

Sorry for lack of overall comments there from me and Adam.  dt_link.c contains
the code for handling USDT, userland statically defined tracing.  dtrace -G
can be used to link programs with these tracepoints defined.  What is happening
in here is that in the user source code, you have calls to the DTRACE_PROBEN
macros that are defined like this:

#define DTRACE_PROBE3(provider, name, arg1, arg2, arg3) {               \
        extern void __dtrace_##provider##___##name(unsigned long,       \
            unsigned long, unsigned long);                              \
        __dtrace_##provider##___##name((unsigned long)arg1,             \
            (unsigned long)arg2, (unsigned long)arg3);                  \
}

So if you write a piece of C code that does something like:

        DTRACE_PROBE3(foo, bar, x, y, z);

you end up with the normal compiler generating code to assemble
the arguments x, y, z and issuing a call to the extern function
__dtrace_foo__bar(x, y, z); which of course doesn't exist.

Then you run dtrace over your object code, and it finds all of these
sequences and replaces the call to that function with no-ops, so that
when instrumentation is disabled nothing happens.  Meantime we also
rewrite the relocations for the call instructions to refer to the
containing function, and insert various bits of ELF to note where
these things are.  Then the PID provider's USDT support can find
them and patch them with instrumentation when DTrace is used.

Aside from all the ELF machinery, the major thing you need to address
with another instruction set is being careful about what happens
when the fake call is part of a tail-call elimination sequence
(you will see special cases for this on SPARC and x64)

-Mike

-- 
Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org

Reply via email to