On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote: > On Fri, 3 Jun 2016 00:40:02 +0900 > Namhyung Kim <namhy...@gmail.com> wrote: > > > Hello, > > > > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval <osan...@osandov.com> wrote: > > > From: Omar Sandoval <osan...@fb.com> > > > > > > ftrace is very quick to give up on saving the task command line (see > > > `trace_save_cmdline()`). The workaround for events which really care > > > about the command line is to explicitly assign it as part of the entry. > > > However, this doesn't work for kprobe events, as there's no > > > straightforward way to get access to current->comm. Add a kprobe event > > > variable $comm which provides exactly that. > > Hmm, would you already tried to trace task/task_newtask and task/task_rename > events? which also gives you task's comm. > Of course there are no way to get running task's comm...
Right, I was trying to figure out what task was hitting a specific code path, so I don't think that would work. > Anyway, I also think more generic idea, e.g. enable to get "current" address. > With the "current" address, we can do similar thing (by using perf-probe) Yeah, that would also be useful in general. I think having this is still convenient for quick debugging. > The code looks good to me. As Namhyung said, it should support uprobes > too. Yesterday I sent out v2 which also supports uprobes, let me know if you didn't receive it. > BTW, now I'm considering integrate kprobes and uprobes ftrace interface. > It is easy to classify given event definition is for kprobes or uprobes. > So, we don't need to have 2 different interfaces for it. > > Thank you, Thanks for taking a look. -- Omar
