From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25016 invoked by alias); 5 Jul 2018 21:05:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24993 invoked by uid 89); 5 Jul 2018 21:05:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=ID, H*c:alternative X-HELO: mail-oi0-f66.google.com Received: from mail-oi0-f66.google.com (HELO mail-oi0-f66.google.com) (209.85.218.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jul 2018 21:04:58 +0000 Received: by mail-oi0-f66.google.com with SMTP id n84-v6so19503237oib.9 for ; Thu, 05 Jul 2018 14:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndmsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VgBhQrqJH7vf02n9Vv4+t5PPDKsHzXSR7th46APhKzE=; b=CsW2q5e74oOccDaMg9Q1gK/JqAYhMGXrC8JgsQ80sk4WpyuuWGNz89ChYFId6zuWdr C2AQBvudIoQQurtzUjm/YcdU5eAGeBozgVEyzGAfsw/Z1LNIbU714efCX7nGQsYxR4Gq YxcQITaxxCTMv/zm8kdlAqt0HlFlnztBLT0i+o/qwrni3sMnEykFWlRwraxiuKRAJcMh 8XcMded37xBa4eyHiOaK454J+fNDAEhcMekOS6LJh9lkCM9FNP+sXnNyfnbELHl8AeAc BOfO4B/tsil0etIXhafy0MYkEKfCm8W6iEqC+eLLfb9GSeLrWCDrQWb3LgbEzG1gYcLT i67w== MIME-Version: 1.0 Received: by 2002:a9d:4b83:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 14:04:16 -0700 (PDT) In-Reply-To: References: <20180703193753.GC2675@embecosm.com> From: Sergey Korolev Date: Thu, 05 Jul 2018 21:05:00 -0000 Message-ID: Subject: Re: [PATCH] MIPS/GDB/linux-nat.c: Fix a child detach condition for uClibc-ng To: "Maciej W. Rozycki" Cc: Andrew Burgess , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00129.txt.bz2 On Thu, Jul 5, 2018 at 3:32 PM, Maciej W. Rozycki 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 >