On Wed, 2010-01-13 at 17:12 -0500, Masami Hiramatsu wrote: > Masami Hiramatsu wrote: > > Steven Rostedt wrote: > >> On Tue, 2010-01-12 at 05:54 +0100, Frederic Weisbecker wrote: > >> > >>> Now what if I want to launch ls and want to profile a function > >>> inside. What can I do with a trace event. I can't create the > >>> probe event based on a pid as I don't know it in advance. > >>> I could give it the ls cmdline and it manages to activate > >>> on the next ls launched. This is racy as another ls can > >>> be launched concurrently. > >> > >> You make a wrapper script: > >> > >> #!/bin/sh > >> <add probe to ls with pid> $$ > >> exec $* > >> > >> I do this all the time to limit the function tracer to a specific app. > >> > >> #!/bin/sh > >> echo $$ > /debug/tracing/set_ftrace_pid > >> echo function > /debug/tracing/current_tracer > >> exec $* > > > > I recommend you to add below line at the end of the script, > > from my experience. :) > > > > echo nop > /debug/tracing/current_tracer > > Oops, my bad, it doesn't work after exec... > But, it is very important to disable function tracer after > tracing target process. > > So, perhaps, below script may work. > > #!/bin/sh > (echo $BASHPID > /debug/tracing/set_ftrace_pid > echo function > /debug/tracing/current_tracer > exec $*) > echo nop > /debug/tracing/current_tracer
Unfortunately, that would lose the entire trace you just recorded. So perhaps adding: trace-cmd extract echo nop > /debug/tracing/current_tracer would work better. The extract feature of trace-cmd pulls the data from the kernel buffer and saves it in a file format. -- Steve