Re: [PATCH] MIPS/GDB/linux-nat.c: Fix a child detach condition for uClibc-ng

Maciej W. Rozycki
2018-07-05T12:32:27Z

On Tue, 3 Jul 2018, Andrew Burgess wrote:

> > Current implementation expects that WIFSTOPPED (W_STOPCODE (0)) is true,
> > but in the uClibc-ng it is false on MIPS. The patch adds a "detach"
> > helper variable to avoid this corner case: WIFSTOPPED applied
> > only to a status filled by a waitpid call that should never return
> > the status with zero stop signal.
>
> I took a quick look through this patch, and have a little feedback.
>
> You might want to expand your commit message to explain _why_ MIPS is
> different (having a signal 127), I didn't know this, and it puzzled me
> for a while as to why your above text didn't just indicate a bug in
> uClibc-ng :)

I think it is a bug in uClibc-ng after all, because you can't receive
signal #0 on Linux. This is what the kernel has (in kernel/signal.c):

/*
* The null signal is a permissions and process existence
* probe. No signal is actually delivered.
*/
if (!error && sig) {
error = do_send_sig_info(sig, info, p, false);
/*
* If lock_task_sighand() failed we pretend the task
* dies after receiving the signal. The window is tiny,
* and the signal is private anyway.
*/
if (unlikely(error == -ESRCH))
error = 0;
}

and also:

if (!ret && sig)
ret = do_send_sig_info(sig, info, p, true);

and documentation for kill(2) agrees:

"If sig is 0, then no signal is sent, but error checking is still per-
formed; this can be used to check for the existence of a process ID or
process group ID."

> [PATCH] gdb: Avoid using W_STOPCODE(0) as this is ambiguous on MIPS
>
> The MIPS target supports 127 signals, and this can create an ambiguity
> in process wait statuses. A status value of 0x007f could potentially
> indicate a process that has exited with signal 127, or a process that
> has stopped with signal 0.
>
> In uClibc-ng the interpretation of 0x007f is that the process has
> exited with signal 127 rather than stopped with signal 0, and so,
> WIFSTOPPED (W_STOPCODE (0)) will be false rather than true as it would
> be on most other platforms.

So there is no ambiguity, 0x007f means that the process has exited with
signal 127 and nothing else, and while I agree the change might be a good
workaround for uClibc-ng's oddity, I think uClibc-ng's implementation of
WIFSTOPPED has also to be fixed to reflect reality. Which also means the
commit description needs to be updated accordingly.

FWIW,

Maciej