On Wed, Oct 01, 2008 at 12:59:15PM -0700, Adam Leventhal wrote:
> On Wed, Oct 01, 2008 at 12:16:07AM -0500, Nicolas Williams wrote:
> > pid$1:libsomelibrary:some_function:entry
> > {
> > self->some_item = copyin_expr("arg[0]->field1->field2->field3");
> > ...
> > }
> >
> > and the D *compiler* looking up the CTF for this and figuring out what
> > sequence of copyins to translace that into, including, possibly,
> > defining a useful struct type for self->some_item.
> >
> > The bitness of the target would have to be known at compile-time, else
> > the compiler would have to generate DOF code for both, 32- and 64-bit
> > targets and branch at run-time according to which the running target is.
>
> We don't even need the copyin_expr() part -- there's no reason we couldn't
> "know" that copyins were implicitly required.
Oh, I know, I didn't mean that it'd have to look like a function.
Native compiler support might look completely different, better
integrated, something like
pid$1:libsomelibrary:some_function:entry
{
self->some_item = arg[0]->field1->field2->field3;
trace(self->some_item.field4);
...
}
If I were building a pre-processor to generate D code to replace such an
expression I'd probably just add a copyin directives section between a
probe's predicate and actions. That would make it easy to extract the
copyin expressions without having to parse the actions.
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
