From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67605 invoked by alias); 6 Jul 2018 22:10:01 -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 67580 invoked by uid 89); 6 Jul 2018 22:10:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_20,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=linux-nat.c, linuxnatc, signals, UD:linux-nat.c X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 22:09:59 +0000 Received: by mail-wm0-f67.google.com with SMTP id v25-v6so16109157wmc.0 for ; Fri, 06 Jul 2018 15:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=P+n3rLMoavAkRuqCSXJl4gFxWan17tx/HRooghHZU+E=; b=XvPXlvEepScNP61tKTwzIRPQTy6KRFga42X/crzBikbOwpGKsBrLGxuB0HspjDZ3HD agbBTXGdKSfZF0H1LxyNLQtrHjy0C66ulq8at4Yx1nCKAe2nmR3IAstK3AJiZakJ/RHb /tFaeDcEw6oov2o7yYDqtzD23pbuWAywOPWx3s4kiSpI6gZyJ5cJRVz/y03+sHrvMoCq w+LmYAI4bXbjbp2BwXagaPBUlci3TEzarWz/FCX19lB5J6xUCmhfISfoAnab50ZF12rj fzMhbwjz50v+szXeX/xioznGtfS5XsrWeChcUw1Z2nHX7s81Nqr7H4558gJzt36G8Ohh L+oA== Return-Path: Received: from localhost (host86-164-199-62.range86-164.btcentralplus.com. [86.164.199.62]) by smtp.gmail.com with ESMTPSA id p184-v6sm6072877wmp.31.2018.07.06.15.09.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Jul 2018 15:09:56 -0700 (PDT) Date: Fri, 06 Jul 2018 22:10:00 -0000 From: Andrew Burgess To: "Maciej W. Rozycki" Cc: Sergey Korolev , gdb-patches@sourceware.org Subject: Re: [PATCH] MIPS/GDB/linux-nat.c: Fix a child detach condition for uClibc-ng Message-ID: <20180706220955.GP2675@embecosm.com> References: <20180703193753.GC2675@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: No skis take rocks like rental skis! X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00156.txt.bz2 * Maciej W. Rozycki [2018-07-05 13:32:06 +0100]: > 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. OK. I think we're mostly agreeing with each other, it's just the part about uClibc-ng which I'd like to push on a bit more. Lets consider a couple of cases, first signal 0x33. Status | Value | Meaning ------------------ 0033 | Killed by signal 0x33 337f | Stopped by signal 0x33 Now, signal 127, or 0xf7: 007f | Killed by signal 0x7f 7f7f | Stopped by signal 0x7f And if we _pretend_ for a moment, that signal 0x00 can be sent: 0000 | Killed by signal 0x00 007f | Stopped by signal 0x00 So the ambiguity arises if we can send both signal 0x7f AND signal 0x00. But, as you point out the kernel prevents sending signal 0x00, and for all targets except MIPS, signal 0x7f is also prevented. Most targets seems to have 32 or 64 signals. MIPS has 128. But this shouldn't be a problem, the kernel (as you point out) prevents us sending signal 0x00. The problem is that signal 0x00 isn't coming from the kernel, it's being synthesised in GDB with 'W_STOPCODE (0)', which builds the status 007f. I might even be bold enough to declare that 'W_STOPCODE (0)' should be declare a bad thing .... maybe ... Still, I don't see how uClibc-ng is doing anything wrong, a status is only a stop status if (a) it ends in 0x7f, and (b) the signal number is non-zero, this seems pretty reasonable really. Thanks, Andrew > > FWIW, > > Maciej