From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90261 invoked by alias); 9 Jul 2018 11:20:47 -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 89599 invoked by uid 89); 9 Jul 2018 11:20:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=HCC:D*org, Hx-languages-length:987, uclibcng, W_STOPCODE X-HELO: 9pmail.ess.barracuda.com Received: from 9pmail.ess.barracuda.com (HELO 9pmail.ess.barracuda.com) (64.235.150.225) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 11:20:45 +0000 Received: from mipsdag02.mipstec.com (mail2.mips.com [12.201.5.32]) by mx27.ess.sfj.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NO); Mon, 09 Jul 2018 11:20:41 +0000 Received: from [10.20.78.95] (10.20.78.95) by mipsdag02.mipstec.com (10.20.40.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1415.2; Mon, 9 Jul 2018 04:20:47 -0700 Date: Mon, 09 Jul 2018 11:20:00 -0000 From: "Maciej W. Rozycki" To: Andrew Burgess CC: Sergey Korolev , Subject: Re: [PATCH] MIPS/GDB/linux-nat.c: Fix a child detach condition for uClibc-ng In-Reply-To: <20180706220955.GP2675@embecosm.com> Message-ID: References: <20180703193753.GC2675@embecosm.com> <20180706220955.GP2675@embecosm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: macro@mips.com X-BESS-Apparent-Source-IP: 12.201.5.32 X-SW-Source: 2018-07/txt/msg00211.txt.bz2 On Fri, 6 Jul 2018, Andrew Burgess wrote: > 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. Right, somehow I didn't fully realise that it is GDB being responsible for creating this status code artificially. Sorry for the confusion. > I might even be bold enough to declare that 'W_STOPCODE (0)' should be > declare a bad thing .... maybe ... I think it would be reasonable for an implementation to require the argument to be a valid signal number and therefore users of this API would have to avoid passing other numbers as that would cause undefined behaviour. > 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. Agreed. Garbage in, garbage out. Maciej