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

Sergey Korolev
2018-07-05T21:05:02Z

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
>