Messages in this thread | | | Date | Fri, 30 Jun 2006 13:47:17 -0700 | From | Stephane Eranian <> | Subject | Re: [PATCH 10/17] 2.6.17.1 perfmon2 patch for review: PMU context switch |
| |
On Fri, Jun 30, 2006 at 07:08:03PM +0200, Andi Kleen wrote: > On Friday 30 June 2006 18:02, Stephane Eranian wrote: > > Andi, > > > > As a first step, I am looking at implementing a TIF_DEBUG > > for x86-64. AFAIK, debug registers must not be inherited on > > fork(). > > Why not? Especially for threads you probably want them > in the new thread too. > For this to work, the new thread must also inherit the ptrace flag and ptrace re-parenting stuff. That would happen under the cover as the ptracing application would not necessarily know about this. It would also need to be able to name that new thread (via gettid() and not getpid()) to be able to operate on it.
In my mind, it has to work the other way around. The ptracing process interesting in ptracing/debugging new threads, sets the right ptrace notification options for CLONE, when it gets the notification it attaches to the newly created thread and reprograms the breakpoints. This is the way I allow a tool such as pfmon, to monitor across fork, pthread_create(), for instance.
Of the top of my head, I think for Itanium, we disable breakpoints for the child in copy_threads(). I don't know for the other architectures.
Anybody can comment on this?
-- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |