RFC: DTrace probes for debugging or testing in userland programs

Hiroki Sato hrs at allbsd.org
Mon Dec 19 23:08:20 UTC 2016


2016/12/20 6:54、Domagoj Stolfa <domagoj.stolfa at gmail.com> のメッセージ:

> Hello,
> 
>> To be clear: my proposal is to replace only debug logging (i.e. for
>> developers), not the other logging in general, as the subject line
>> says.  Although I agree that DTrace is not lightweight, I think
>> impact of just adding tracing probes is small.
>> 
>> -- Hiroki
> 
> I believe this would indeed be beneficial for debugging. My main concern
> is the way that we would have to attach to probes should we use SDT
> provider as it works now. If we were to create probes for each of the
> daemons, which we would then run individually, and if I'm not mistaken,
> that would spawn 2 times the amount of processes than are currently 
> spawned due to each ``dtrace'' call from the command line spawns a process.

No.  A single dtrace process can catch
fired probes of multiple processes if you want.

Filtering probes or the results from probes
is things which should be done in the
D script level, not in the target binary,
in the case of DTrace.  My proposal does
not cover how to use the probes.  It just
provides probes and a sample script to
reproduce the (almost) same results with
printf() debug logging.  The big difference
is that a developer can use these probes
for a more complex debug script and/or
regression test script because the
probes can carry data structures in
question, not just a string.

-- Hiroki


More information about the freebsd-arch mailing list