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/
[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]