This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix attaching to Linux stopped processes
On Sat, 23 Sep 2006 19:36:37 +0200, Mark Kettenis wrote:
...
> > Also the patch looks right to me - after `PT_ATTACH' it is appropriate that
> > `WSTOPSIG (status)' will report the original signal that stopped process,
> > (WSTOPSIG (status) == SIGSTOP) <=> (process was in running/sleeping mode).
>
> Whoa stop, the status returned by wait(2) doesn't tell you whether a
> process is sleeping or running. Traditionally, after invoking
> ptrace(PT_ATTACH, ...) the kernel will always respond with a SIGSTOP.
> Any information about any previous signals is lost.
(Red Hat) kernel 2.6.17-1.2647.fc6 reports SIGSTOP for running processes and
0 for processes already stopped before ptrace(PTRACE_ATTACH). It does not
differentiate SIGTTIN vs. SIGSTOP etc., though, as I expected, thanks.
I found in POSIX that the waitpid(2) vs. ptrace(2) behavior is underfined:
http://www.opengroup.org/onlinepubs/009695399/functions/wait.html
Since ptrace() is not part of this volume of IEEE Std 1003.1-2001,
[ I did not find any other ptrace(2) on http://www.opengroup.org/ . ]
> This all smells like a race condition in the kernel to me. The
> linux-nat.c code is quite hairy already. I'd suggest fixing the
> kernel rather than adding more workarounds.
Do you have some standard/specification to follow?
I found more that the WSTOPSIG() _should_ report the specific signal:
http://www.scit.wlv.ac.uk/cgi-bin/mansec?3B+wait4
the 8 bits higher up from the low-order 8 bits of w_status contain the
number of the signal that caused the process to stop.
See ptrace(2) and sigvec(3UCB).
Regards,
Jan