Hi Martin,
On Thu, Jul 11, 2019 at 05:45:58PM +0000, Martin, Wilson wrote:
> So, this is mainly for a kernel function. Details below:
> unsigned int get_random_int(void);
>
> lttng enable-event get_random_int --kernel --function get_random_int
>
> get_random_int_entry: { cpu_id = 0 }, { pid = 22596, tid = 22596 }, { ip =
> 0xFFFFFFFF8152B8B0, parent_ip = 0xFFFFFFFF8106F8B5 }
> get_random_int_return: { cpu_id = 0 }, { pid = 22596, tid = 22596 }, { ip =
> 0xFFFFFFFF8152B8B0, parent_ip = 0xFFFFFFFF8126CC6A }
>
> I don’t get the return value from the trace. So, how do I capture that?
> And, for other kernel functions, how do I capture the function arguments?
>
> Regarding the kernels built-in ftrace system, you can capture any functions
> arguments and return value. The ftrace syscall capture is a good example:
> (NR=0 -> sys_read)
> sshd-20065 [000] 1987131.702871: sys_enter: NR 0 (b, 30f64380,
> 4000, 8, 0, 0)
> sshd-20065 [000] 1987131.702871: sys_exit: NR 0 = 2
I do not play a lot with ftrace, is there an equivalent to:
lttng enable-event get_random_int --kernel --function get_random_int
that returns the passed arguments and the return value?
>
> Example from lttng syscall capture, with args and return:
> syscall_entry_read: { cpu_id = 0 }, { pid = 22596, tid = 22596 }, { fd = 3,
> count = 832 }
> syscall_exit_read: { cpu_id = 0 }, { pid = 22596, tid = 22596 }, { ret = 832,
> buf = 140722751121336 }
>
> So, let’s also say that the built-in capabilities just don’t support what I
> want.
> What if I were to develop a custom kernel probe using the LTTNG_* macros?
A good starting point would be to look at how other probe are done.
This would be here:
https://github.com/lttng/lttng-modules/tree/a6a26911cc7888458bd91feb433df584d7dcd5c8/instrumentation/events
> How would I go about capturing some named function (non-tracepoint)? And, its
> arguments and return value?
I dot now know how we could add this functionality. Mathieu Desnoyers might
have some insight here. He is on vacation for two weeks.
> How would I go about making a custom syscall probe that adds additional
> arguments to the context?
Again I would start with how it is done for other syscalls:
https://github.com/lttng/lttng-modules/tree/9f36eaed6f91d5897924b551b44d1edd8cee00e2/instrumentation/syscalls
>
> I guess I could code my own ftrace hook function, put a custom tracepoint in
> the code, and then use the macros to push into lttng ring buffers. Maybe?
That would be the equivalent of supporting a new event. Yes.
I hope this help a bit.
Cheers
--
Jonathan Rajotte-Julien
EfficiOS
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
