Messages in this thread | | | Date | Mon, 31 Jul 2006 15:00:18 -0400 | From | Daniel Jacobowitz <> | Subject | Re: ptrace bugs and related problems |
| |
On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote: > I was using the data to look up which task just got split away > from the parent. Judging by Chuck Ebbert's email, I'm not the > only person to expect the data to be valid.
So it seems! It seems a reasonable addition if anyone wants to submit it.
> >Or just present things as if the leader task did the execve, which is > >effectively what happens, and what I thought would happen for ptrace > >too. > > That makes things even weirder. A successful execve done in one > thread appears to be done by another (which might not be > traced if the debugger was a bit odd), while a failing execve > appears... where?
Not at all, unless you're doing syscall tracing, I don't think. The exec notification is after the mm is replaced.
> >The interface was never designed to handle unsharing. I don't really > >think it should be extended to; whoever needs this functionality should > >design something cleaner for utrace. > > I'm not sure utrace will be accepted. (many ptrace alternatives > have been born and died over the years) Even if utrace does get > accepted, initially we only get: > > 1. a clean-up that provides hope for the future > 2. a hopefully-compatible ptrace on top of utrace > 3. some sort of demo interface > > That alone won't replace ptrace.
That's why I suggested someone design a cleaner debugging interface to be implemented on top of utrace - which is how it's supposed to be used. Like David, I am confident that this is the future direction of Linux debugging.
> >> PTRACE_GETSIGINFO has 0x0605 as si_code when a process exits. > >> This is not defined anywhere. > > > >It's garbage. PTRACE_GETSIGINFO is only valid after the process stops > >with a signal. > > The process does indeed stop with a signal. It gets SIGTRAP > as part of sending the ptrace event.
Sure, but you must know what I meant. PTRACE_GETSIGINFO is only valid when there is a real signal, i.e. generated by something other than ptrace. Which is true whenever wait reports a signal without any of the special event bits set (except for the legacy SIGTRAP on execve).
-- Daniel Jacobowitz CodeSourcery - 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/
| |