Messages in this thread | | | Subject | Re: [RFC 0/4] tracing,x86_64 - function/graph trace without mcount/-pg/framepointer | From | Steven Rostedt <> | Date | Thu, 03 Feb 2011 11:33:25 -0500 |
| |
On Thu, 2011-02-03 at 16:42 +0100, Jiri Olsa wrote: > hi, > > I recently saw the direct jump probing made for kprobes > and tried to use it inside the trace framework. > > The global idea is patching the function entry with direct > jump to the trace code, instead of using pregenerated gcc > profile code.
Interesting, but ideally, it would be nice if gcc provided a better "mcount" mechanism. One that calls mcount (or whatever new name it would have) before it does anything with the stack.
> > I started this just to see if it would be even possible > to hook with new probing to the current trace code. It > appears it's not that bad. I was able to run function > and function_graph trace on x86_64. > > For details on direct jumps probe, please check: > http://www.linuxinsight.com/ols2007-djprobe-kernel-probing-with-the-smallest-overhead.html > > > I realize using this way to hook the functions has some > drawbacks, from what I can see it's roughly: > - no all functions could be patched
What's the reason for not all functions?
> - need to find a way to say which function is safe to patch > - memory consumption for detour buffers and symbol records > > but seems there're some advantages as well: > - trace code could be in a module
What makes this allow module code?
ftrace could do that now, but it would require a separate handler. I would need to disable preemption before calling the module code function handler.
> - no profiling code is needed > - framepointer can be disabled (framepointer is needed for > generating profile code)
Again ideally, gcc should fix this.
-- Steve
| |