Can you specify how the target subset of threads may be identified by
the instrumentation?

(In reply to comment #4)
> ------- Comment From fche 2008-09-22 13:09:05 EDT-------
> Can you specify how the target subset of threads may be identified by
> the instrumentation?

The user specifies the thread-id of interest.
Since utrace provides a per thread engine with callbacks to syscalls, signals,
there would be minimal penalty on the other threads.
What is targeted is a strace like utility (or a systemtap script) that builds on
utrace implementation to list systemcalls, signals.

OK, it sounds like all you want is that the syntax

  probe process(PID).* { }

allow PIDs to match kernel task->pid (thread-id) not just task->tgid (process-id).
It would not be hard to have some syntax for that:

  probe thread(TID).{begin,end,syscall,...} { }

though uprobes style probes like .function/.statement are per-process,
so would have to be emulated per-thread if they were at all desirable.

(In reply to comment #6)
> ------- Comment From fche 2008-09-25 09:28:38 EDT-------
> OK, it sounds like all you want is that the syntax
>
> probe process(PID).* { }
>
> allow PIDs to match kernel task->pid (thread-id) not just task->tgid (process-id).
> It would not be hard to have some syntax for that:
>
> probe thread(TID).{begin,end,syscall,...} { }
>
> though uprobes style probes like .function/.statement are per-process,
> so would have to be emulated per-thread if they were at all desirable.

yes the current requirement is for utrace style probes.
uprobes style probes are not a requirement but surely desirable to probe allow
function entry/exit
(more like per-thread-ltrace) but I feel statement probes would make it more heavy.

No patch for this feature yet, design also incomplete.

------- Comment From srikar.ibm.com 2009-10-01 04:10 EDT-------
(In reply to comment #9)
> No patch for this feature yet, design also incomplete.
>

Some of the features requested by this bug are already implemented in utrace.
Here is the list of requests
1. Request for a thread to be quiesced without having to use SIGNALS.

(We already have support for this in utrace. However there is no easy way for current user space debuggers to use this feature. This could be addresssed if and when utrace has its own user space API)

2. Ability to trace just one thread of a multithreaded process for activity so that there is no penalty for other threads.
(We already have support for this in utrace/uprobes. Though SystemTap is able to exploit utrace/uprobes, It might not be complete with respect to no penalty on other threads. Also there could be user space debuggers who are  interested in exploiting this feature. This could also be addresssed if and when utrace has its own user space API).

As noted earlier, the request is for system call tracing per thread for process. However providing library function tracing per thread of a process would be great.

3. Reliably distinguish between different reasons for SIGTRAP.
(We already have support for this in utrace thro report_signal handler())

Reliable hardware-breakpoints was also part of the thread level debugging requests. However I think its been tracked by a different bug and also there is already considerable work done in this area, This is up for discussion in LKML by K Prasad thro this patches.

We have been unable to build this in time for rhel6.0.

http://sourceware.org/bugzilla/show_bug.cgi?id=11212 now tracks this.

Removing from RHEL 6.0 tracker, adding to 6.1 tracker.

Unfortunately, the systemtap PR11212 aspect has slipped through the cracks;
perhaps next version.

If there is still as sense that a non-systemtap solution to the above
issues is a priority, we should raise that in other longer-term fora.
How much interest is there at IBM to help define interfaces and build tools?

Closing as DEFERRED since this is not in plan for RHEL 6.1.  Please feel free to reopen when the 6.2 feature queue is opened.