* Frank Ch. Eigler (f...@redhat.com) wrote:
Hi -
On Mon, Mar 16, 2009 at 05:45:26PM -0400, Mathieu Desnoyers wrote:
[...]
As far as I know, utrace supports multiple trace-engines on a process.
Since ptrace is just an engine of utrace, you can add another engine on
utrace.
The utrace API itself is not a good fit for global tracing, since its
purpose is tracing and control of individual user threads. There is
no reason to allocate its per-task data structures when you are going
to treat all tasks the same anyway. The points that I think are being
missed are about
Hi -
On Mon, Mar 16, 2009 at 05:45:26PM -0400, Mathieu Desnoyers wrote:
[...]
As far as I know, utrace supports multiple trace-engines on a process.
Since ptrace is just an engine of utrace, you can add another engine on
utrace.
utrace-+-ptrace_engine---owner_process
|
On Mon, Mar 16, 2009 at 06:18:00PM -0400, Frank Ch. Eigler wrote:
Hi -
On Mon, Mar 16, 2009 at 05:45:26PM -0400, Mathieu Desnoyers wrote:
[...]
As far as I know, utrace supports multiple trace-engines on a process.
Since ptrace is just an engine of utrace, you can add another
On 03/16, Mathieu Desnoyers wrote:
utrace_add_engine()
set_notify_resume(target);
ok, so this is where the TIF_NOTIFY_RESUME thread flag is set. I notice
that it is set asynchronously with the execution of the target thread
(as I do with my TIF_KERNEL_TRACE thread flag).
However, on
