[DTrace-devel] timestamp patch

[Kris Van Hees]

On Sat, Jul 18, 2020 at 11:12:41AM -0400, eugene.loh at oracle.com wrote:
> In retrospect, this patch should probably wait until Kris has
> finished putting back his compiler changes.  Ah well.  Take a
> look if you like.
> 
> I am curious about one thing.  With legacy DTrace,
>         BEGIN{trace(timestamp)}
>         BEGIN{trace(timestamp)}
> would return two different values.  Once Kris's compiler changes
> are finished, will those two clauses be squashed to
>         BEGIN{trace(timestamp);
>               trace(timestamp)}
> resulting in the same value being reported both times?  Again,
> I'm simply curious.  Such a change in semantics is both subtle
> and arguably even desirable.

Actually, that is not what will happen.  Semantics are retained, because what
will really happen is that when the BEGIN probe fires, the trampoline program
will call two functions, one for each clause.  Since the prologue of the
clause will be resetting the stored timestamp on the mstate, each clause will
retrieve its own value that will remain consistent for the execution of that
particular clause.

By the way, the reason for this being necessary is that there may be multiple
clauses on the same probe within a single program but there may also be clauses
for a given probe across multiple programs (a program is something that is
specified as argument to the -P, -m, -f, -n, -i, or -s options).  Programs
are compiled as almost entirely distinct compilations (aside from the global
variable table), so merging code that has been compiled in different programs
is actually really complicated.  But compiling clauses into functions that are
then called from the trampoline is a lot easier since we already have a linker
implemented.

	Kris