These are some of the concepts that first confused me when looking at a dynamic trace environment. This is really a continuation of the previous slide, but with a focus on what hurt my brain the most when I first looked at dynamic tracing.

The event driven nature of the language is not too hard to grasp, it just makes the code seem awkward at first.

Understanding that libc calls are not syscalls was one of the first problems I ran into when attempting to write a script. The syscallx provider in Vue and the Ðl (ell) option to dtrace can be useful in determining what is a syscall and what can be probed. The gethostbyname() example is a libc call that can be probed by the UFT provider Ð but UFT probes are not system wide, and it is not used by all applications that look up names.

The different ÒmeaningsÓ of the word ÒtraceÓ can be confusing. Here is a simple glossary:

trace() Ð A raw ÒdumpÓ of a variable passed as a parameter. This is an API that takes a data item as a parameter. printf() is a close equivalent.

Tentative tracing Ð The ability to send data to output (without committing it) and then, later, actually printing it or discarding it.

trace buffers Ð The output of the probevue command. A close analogy would be the stdout buffer. Unlike stdout, trace buffers do not ÒblockÓ and can be overrun with excessive data.

trace provider Ð This is a provider that is actually the legacy trace command. It uses the same hooks from trace but they are available within Vue as a probe point.

There are examples of a thread local variable here in this presentation.

Memory (pointers) that you get from a syscall (or similar provider) are pointers that are relevant in another process. The memory must be paged in, and only then can it be copied into the probevue environment. Once it is in the local probevue environment, it can be searched, managed, printed, etcÉ