Re: [PATCH 10/17] 2.6.17.1 perfmon2 patch for review: PMU context switch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux