> In looking at the code I was wondering something. What happens to the
> real parent of a ptraced task when it calls wait4()? If that's its only
> child, won't it return ECHILD?
hm, so this could be fixed by iterating over the ptraced tasks as well
when doing a wait4.
the problem is that the debugger wants to do a wait4 as well, to receive
the SIGSTOP result. Now if the original parent 'steals' the wait4 result,
what will happen?
this whole mess can only be fixed by decoupling the ptrace() mechanism
from signals and wait4 completely, it's a nasty relationship that infests
both the kernel and userspace code [check out strace.c once to see the
kind of pain it has to go through to isolate ptrace events from other
signals.]
I'm not quite sure whether this is possible, how deeply do ptrace
applications depend on a real SIGSTOP signal interrupting the task? Would
it be equally good if it was a different interruption/signalling method
that did this? [with a few minor and straightforward cleanups to entry.S i
think we could use a task ornament flag for ptrace interruption. This
would result in a few orders better behavior on all fronts.]
Ingo
-
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/