2

I've tried these, but all of them produce "empty" output files:

trace-cmd record -p function_graph -g munmap -F ls
trace-cmd record -p function_graph -g sys_enter_munmap -F ls
trace-cmd record -p function_graph -g sys_enter -F ls
Robin Green
  • 32,079
  • 16
  • 104
  • 187
  • Are you sure ftrace is enabled? – gby Apr 09 '11 at 17:49
  • Yeah, it works if I just tell it to dump all events. – Robin Green Apr 09 '11 at 19:09
  • Well, I tried these and they work here (Ubuntu 2.6.35-28,trace-cmd version 1.0.3 ) so I would guess the problem lies in your specific kernel or ftrace-cmd version and/or config. – gby Apr 10 '11 at 06:58
  • What command did you use to view the output? What kind of output did you get? – Robin Green Apr 10 '11 at 07:05
  • First I used vi to verify I have content in trace.dat. Then I used kernelshark to visualize the log. – gby Apr 10 '11 at 07:10
  • That's odd, I would have thought that only one of the above commands would have worked. – Robin Green Apr 10 '11 at 07:12
  • 1
    hmm... seems something is fishy indeed. I tried now the command: " trace-cmd record -p function_graph -g xxx -F ls " And it seems to produce the same output. I don't think the filtering works... :-) – gby Apr 10 '11 at 07:37

1 Answers1

3

First you need to get the function name right - e.g. the function name to use for tracing open syscalls is sys_open.

To do this the "proper" way, it's necessary to have function_graph support in the kernel. On the x86 architecture this depends on CC_OPTIMIZE_FOR_SIZE being disabled, but on x86_64 it doesn't.

In my case I didn't bother to compile a custom kernel to disable CC_OPTIMIZE_FOR_SIZE, I just did 

trace-cmd record -p function --func-stack

and included various functions that looked like they might be called by adding several -l options. This was enough to figure out what I wanted to know.

Robin Green
  • 32,079
  • 16
  • 104
  • 187