Discussion:
tracing at start and end for some trace events
Du, Yuyang
2014-05-13 03:26:07 UTC
Permalink
Hi Steven,

I posted some time ago to query about this, but I would like to request this feature again.

That is to intentionally trace or write something at the start and end of a tracing session (trace on and off).

I will give you an example about what and how I do it as of now:

I first defined an traceevent: XYZ. Then I add this in tracer_tracing_on(): trace_XYZ(some hardware register values) and also in tracer_tracing_off(): trace_XYZ(some hardware register values).

Having done that, I have the HW values at least at the start and end, because the worst case is I may not have hit the regular XYZ event tracepoint in the whole session.

Does it make sense?

Thanks,
Yuyang


--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yuyang Du
2014-05-13 17:35:28 UTC
Permalink
Post by Du, Yuyang
Does it make sense?
I think so, but it is extremely "specific" to your issue, and not
something that I would think would be a generic feature.
That said, I think you can accomplish this with kprobes. You can
objdump the vmlinux to find the code for tracing_on() and tracing_off()
or better yet, use the ring_buffer_record_on/off(). You can hook a
probe to that point and have it record whatever register you like.
Make sure that the recording happens while tracing is still on. Add the
probe after a tracing_off() or before a tracing_on() will be rather
useless as the probe wont be recorded.
I appreciate your consideration. No argument. But if for the generality of
this feature, it would be like giving entries in DEFINE_EVENT like: TP_START
and TP_END, in which author can write any codes for the *general* health of the
trace event. I would be the first user if allow me, and probably more users
who also want this subconisciously.

Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Steven Rostedt
2014-05-14 19:55:11 UTC
Permalink
On Wed, 14 May 2014 01:35:28 +0800
Post by Yuyang Du
I appreciate your consideration. No argument. But if for the generality of
this feature, it would be like giving entries in DEFINE_EVENT like: TP_START
and TP_END, in which author can write any codes for the *general* health of the
trace event. I would be the first user if allow me, and probably more users
who also want this subconisciously.
If you are talking about simply calling some function when an event is
enabled and disabled, that already exists.

See TRACE_EVENT_FN().

The "reg" is called when the tracepoint is enabled, and the "unreg" is
called when it is disabled.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yuyang Du
2014-05-14 17:29:54 UTC
Permalink
Post by Steven Rostedt
On Wed, 14 May 2014 01:35:28 +0800
Post by Yuyang Du
I appreciate your consideration. No argument. But if for the generality of
this feature, it would be like giving entries in DEFINE_EVENT like: TP_START
and TP_END, in which author can write any codes for the *general* health of the
trace event. I would be the first user if allow me, and probably more users
who also want this subconisciously.
If you are talking about simply calling some function when an event is
enabled and disabled, that already exists.
See TRACE_EVENT_FN().
The "reg" is called when the tracepoint is enabled, and the "unreg" is
called when it is disabled.
Thanks, Steven. So maybe I can use TRACE_EVENT_FN: first enable
tracing (tracing_on), and then enable event, so I can take a snapshot in "reg".
Is that right? I will try it.

Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...