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

[Sergey Korolev <s.korolev@ndmsystems.com>]

On Thu, Jul 5, 2018 at 3:32 PM, Maciej W. Rozycki <macro@mips.com> wrote:

> 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.
>

Here is an initial discussion with an explanation from uClibc-ng patch
author

https://mailman.uclibc-ng.org/pipermail/devel/2018-June/001695.html

Also I do not why but musl does not have W_STOPCODE macro at all.


>  FWIW,
>
>   Maciej
>