[DTrace-devel] [PATCH 1/2] Add clause flags
Kris Van Hees
kris.van.hees at oracle.com
Tue Sep 15 23:07:23 PDT 2020
On Tue, Sep 15, 2020 at 10:24:47PM -0700, Eugene Loh wrote:
> Suggestions incorporated, except for that business of setting the
> DATAREC flag in dt_cg_store_value(). See questions below.
>
>
> On 09/15/2020 09:50 PM, Kris Van Hees wrote:
>
> > On Tue, Sep 15, 2020 at 10:26:35PM -0400, eugene.loh at oracle.com wrote:
> >> From: Eugene Loh <eugene.loh at oracle.com>
> >>
> >> There are compile-time rules to enforce regarding which actions are
> >> compatible with which others. E.g., data-recording actions cannot
> >> follow commits, etc. Introduce flags that track clause actions during
> >> compilation so that these rules can be enforced.
> >>
> >> diff --git a/libdtrace/dt_cg.c b/libdtrace/dt_cg.c
> >> @@ -589,6 +601,16 @@ dt_cg_act_exit(dt_pcb_t *pcb, dt_node_t *dnp, dtrace_actkind_t kind)
> >> struct bpf_insn instr;
> >> dt_irlist_t *dlp = &pcb->pcb_ir;
> >> uint_t off;
> >> + int *cfp = &pcb->pcb_stmt->dtsd_clauseflags;
> >> +
> >> + /* process clause flags */
> >> + if (*cfp & DT_CLSFLAG_SPECULATE)
> >> + dnerror(dnp, D_EXIT_SPEC,
> >> + "exit( ) may not follow speculate( )\n");
> >> + if (*cfp & DT_CLSFLAG_COMMIT)
> >> + dnerror(dnp, D_DREC_COMM,
> >> + "data-recording actions may not follow commit( )\n");
> >> + *cfp |= DT_CLSFLAG_EXIT | DT_CLSFLAG_DATAREC;
> > This should only set DT_CLSFLAG_EXIT, and the DT_CLSFLAG_DATAREC should be set
> > in dt_cg_store_val() since that is the function that calls dt_add_rec() and
> > then also generates the instructions to actually write the value to the output
> > buffer.
>
> I do not understand the rationale. It would seem to me that here is a
> perfectly fine place to set the DATAREC flag. We know what the action
> is: it's exit(). We need not care about how the action is implemented
> (whether with a call to dt_cg_store_val, direct calls to dt_add_rec, or
> whatever). Indeed, we just tested for D_DREC_COMM ("data-recording
> actions may not... blahblahblah"). So we have said definitively that
> this is a data-recording action, regardless of how we now implement that
> action.
OK
> >> dt_cg_node(dnp->dn_args, &pcb->pcb_ir, pcb->pcb_regs);
> >>
> >> @@ -638,6 +660,13 @@ dt_cg_act_printf(dt_pcb_t *pcb, dt_node_t *dnp, dtrace_actkind_t kind)
> >> dt_pfargv_t *pfp;
> >> char n[DT_TYPE_NAMELEN];
> >> char *str;
> >> + int *cfp = &pcb->pcb_stmt->dtsd_clauseflags;
> >> +
> >> + /* process clause flags */
> >> + if (*cfp & DT_CLSFLAG_COMMIT)
> >> + dnerror(dnp, D_DREC_COMM,
> >> + "data-recording actions may not follow commit( )\n");
> >> + *cfp |= DT_CLSFLAG_DATAREC;
> > See comment above about setting DT_CLS_FLAG_DATARC from dt_cg_store_val().
>
> Actually, the printf action is a better example of what I'm talking
> about. The subsequent code has different code paths: one that calls
> dt_rec_add() directly and the other is a call to dt_cg_store_val(). We
> should set the DATAREC flag because of what we know about the action,
> not because of what we know about the various functions we use to
> implement it -- that is, that a side effect of dt_cg_store_val is to set
> the DATAREC flag while dt_rec_add does not have such a side effect.
>
> >> /*
> >> * Ensure that the format string is a string constant.
> >> @@ -810,6 +853,13 @@ dt_cg_act_trace(dt_pcb_t *pcb, dt_node_t *dnp, dtrace_actkind_t kind)
> >> char n[DT_TYPE_NAMELEN];
> >> dt_node_t *arg = dnp->dn_args;
> >> int type = 0;
> >> + int *cfp = &pcb->pcb_stmt->dtsd_clauseflags;
> >> +
> >> + /* process clause flags */
> >> + if (*cfp & DT_CLSFLAG_COMMIT)
> >> + dnerror(dnp, D_DREC_COMM,
> >> + "data-recording actions may not follow commit( )\n");
> >> + *cfp |= DT_CLSFLAG_DATAREC;
> > See comment above about setting DT_CLS_FLAG_DATARC from dt_cg_store_val().
> >
> >> if (dt_node_is_void(arg)) {
> >> dnerror(arg, D_TRACE_VOID,
>
>
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel
More information about the DTrace-devel
mailing list