[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From dsmith at redhat dot com  2009-03-02 14:55 -------
(In reply to comment #5)
> I once tried to implement the functions using task_finder. The basic code is
> like the following
> 
> #include "task_finder.c"
> static char _stp_taskname[TASK_COMM_LEN]="";
> static int _stp_process_search_cb(struct stap_task_finder_target *tgt, struct
> task_struct *tsk, int register_p, int process_p) {
>   if (register_p) { /* found one match */
>         if (tsk == NULL) {
>                 strlcpy(_stp_taskname, "UNKNOWN", MAXSTRINGLEN);
>                 return 1;
>         } else {
>                 strlcpy(_stp_taskname, tsk->comm, MAXSTRINGLEN);
>                 return 0;
>         }
>   }
>   return 1;
> }
> 
> function pid2execname2:string(pid:long) %{ /* pure */
>         struct stap_task_finder_target tgt;
>         tgt.pathname = NULL;
>         tgt.pid = (pid_t)(long)THIS->pid;
>         tgt.callback = &_stp_process_search_cb;
>         tgt.vm_callback = NULL;
>         stap_register_task_finder_target(&tgt);
>         stap_start_task_finder();
>         strlcpy(THIS->__retvalue, _stp_taskname, MAXSTRINGLEN);
>         stap_stop_task_finder();
>         CATCH_DEREF_FAULT();
> %}
> 
> But it can't return the execname of most running processes like init, mingetty,
> kjournald because the callback is never invoked.
> Only works fine on my forked test process. My box is 2.6.27.9-159.fc10.i686.

The task_finder will never be able to return the execname or pathname of kernel
threads, like 'init' or 'kjournald'.  The 'u' in 'utrace' stands for 'user' - it
only works on user threads.  I'm unsure of why 'mingetty' couldn't be found.

> Did I miss something or misunderstand the mechanism?

Besides the above problem of returning the execname/pathname for kernel threads,
there are other things that won't work well in the code you posted.  As
currently written, the task_finder isn't designed to register new targets while
running (since there is no locking provided) or to be started/stopped more than
once.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6525

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.