[DTrace-devel] [PATCH 04/20] cg: add dt_cg_trace

[Nick Alcock]

On 18 May 2022, Eugene Loh via DTrace-devel verbalised:

> My opinion on this... remains unchanged!  The basic functionality seems really attractive, but I don't like the interface.

Well, Kris suggested one interface and you suggested another
incompatible one. I have to pick one :)

> I think it would be nice to mimic the functionality of bpf_trace_printk() more closely.  That is, allow three values to be 
> printed.  Further, let each one be an IMM or REG.  I know we disagreed on what a sensible interface could look like, but that
> strikes me as a solvable problem.  The current interface with "counter" serving two very 
> different purposes sets the bar low.

Well yes, if can find a nicer interface I'll use it: but I tried the one
you suggested (with all the bit-shifts) and I couldn't enter a single
trace value without screwing it up half a dozen times, which for a
debugging interface is somewhat unhelpful! I'd need a helper function to
wrap the tracing helper function and make it usable :P

> Further, controlling the operation with debugging= also strikes me as
> weird.  That build setting is for GCC optimization, while the current

I intended it as something that controls debugging things that are
expensive enough that you'd only ever want to turn them on when
debugging DTrace, and never have them in production. Turning off
optimization is one of those things: adding stuff to the BPF preamble
that is never called unless you add explicit debugging calls seems like
another one to me.

> Finally I'm curious why the BPF C file is called trace-ptr.c and why that argument is called ptr.  Not a big deal but "ptr" seems
> like a counterintuitive name.

Because it's tracing a pointer value? ... actually I had to change it to
a uint64_t, but it's *conceptually* a uintptr_t :P this will be true
everywhere but CHERI, where pointers are 128 bits :/ ok that name does
suck. trace_long.c, perhaps?

> Anyhow my $0.02.

Good points! And I don't like this interface either -- I just like all
the others proposed so far even less...