On Sat, 25 Aug 2018 12:54:07 +0530
Sai Prakash Ranjan <saiprakash.ranjan@xxxxxxxxxxxxxx> wrote:
> Ftrace does not trace __raw{read,write}{b,l,w,q}() functions. I am not
> sure why and how it is filtered out because I do not see any notrace
> flag in those functions, maybe that whole directory is filtered out.
> So adding this functionality to ftrace would mean removing the notrace
> for these functions i.e., something like using
> __raw{read,write}{b,l,w,q}() as the available filter functions. Also
> pstore ftrace does not filter functions to trace I suppose?
It's not traced because it is inlined. Simply make the __raw_read
function a normal function and it will be traced. And then you could
use ftrace to read the function.
If this has to be per arch, you can register your callback with the
REGS flags, and pt_regs will be passed to your callback function you
attached to __raw_read*() as if you inserted a break point at that
location, and you can get any reg data you want there.
>
> Coming to the reason as to why it would be good to keep this separate
> from ftrace would be:
> * Ftrace can get ip and parent ip, but suppose we need extra data (field
> data) as in above sample output we would not be able to get through ftrace.
As mentioned above, you can get regs (and ftrace is being expanded now
to get parameters of functions).
>
> * Although this patch is for tracing register read/write, we can easily
> add more functionality since we have dynamic_rtb api which can be hooked
> to functions and start tracing events(IRQ, Context ID) something similar
> to tracepoints.
> Initially thought of having tracepoints for logging register read/write
> but I do not know if we can export tracepoint data to pstore since the
> main usecase is to debug unknown resets and hangs.
I don't know why not? We have read/write tracepoints for
read/write_msr() calls in x86.
Anything can add a hook to the callback of the tracepoints, and use
that infrastructure instead of creating yet another dynamic code
modification infrastructure.
>
> * This can be something similar to mmiotrace in x86 and kept seperate
> from function tracer.
mmiotrace is separate because it faults on writes so that we can
capture any reads and writes to the system that a binary driver does.
-- Steve
