[lttng-dev] Difficulty extending existing tracepoint's reporting

[David Boles]

I am trying to widen the information reported by the block_rq_complete()
tracepoint, but am unable to get my extension to take affect. Basically,
I'd like 3 additional numbers captured at that point.

So far, I've failed to succeed in this effort. As part of trying to
determine what is going on, I've created a new tracepoint definition in
include/trace/event/block.h which defines block_rq_complete_ex, which is
just like block_rq_complete but with my additional fields. I've altered the
trace_block_rq_complete() call in block/blk-core.c to be
trace_block_rq_complete_ex().

Other than block_rq_complete being mentioned in blktrace.c (which *seems*
to be unrelated to the LTTng tracing), everywhere there is a mention of
block_rq_complete there is a matching mention of block_rq_complete_ex.

When I build a kernel (LTTng built in mode), the resulting kernel has
block_rq_complete_ex text in it. When I boot it, start an LTTng session,
and list the kernel tracepoints - my new tracepoint isn't listed. If I've
put a new printk in the kernel, it's output is visible. Any ideas on what
I'm missing? Things I've checked:

 - Built from a distclean'd kernel tree
 - lttng is "built in" (I ran the scripts/built_in.sh script and confirmed
the CONFIG_* flags
 - I can enable the original block_rq_complete tracepoint and collect data
through it
 - If instead of having a new tracepoint I just extend the old one, the new
data doesn't show up

It really seems like there is a cached or overriding definition of these
tracepoints that I'm getting instead of what I've compiled. There are
multiple kernels on the system, but I am booting the kernel I intend to.

Any ideas would be highly appreciated.

 - db
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20191014/c62f5880/attachment.html>