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