Alan, On Wed, Feb 28, 2007 at 07:01:17PM -0500, Alan Stern wrote: > On Wed, 28 Feb 2007, Roland McGrath wrote: > > > It is true that debug registers are inherited by fork and clone. > > I am 99% sure that this was never specifically intended, but it > > has been this way for a long time (since 2.4 at least). It's an > > implicit consequence of the do_fork implementation style, which > > does a blind copy of the whole task_struct and then explicitly > > reinitializes some individual fields. I suppose this has some > > benefit or other, but it is very prone to new pieces of state > > getting implicitly copied without the person adding that new state > > ever consciously deciding what its inheritance semantics should be. > > > > Alan Stern is working on a revamp of the x86 debug register > > support. This is a fine opportunity to clean this area up and > > decide positively what the semantics ought to be. > > Absolutely. Right now I just have a placeholder function with a note > about checking for CLONE_PTRACE. The cleanest solution, far and away, > would be to have the child process inherit no breakpoints and no debug > register values. > I agree and that is how we have it on IA-64. With debugging, there is always another process involved and no matter what I think it needs to be aware of the new child. I don't think autoamtic inheritance is good. It should always be trigger by the controlling process (e.g., debugger). There is enough support in ptrace to catch the fork/vfork/pthread_create and decide what to do. This is how I have coded perfmon so that hardware performance counters are never automatically inherited. -- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|