From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id COtyCBhmcGC8MgAAWB0awg (envelope-from ) for ; Fri, 09 Apr 2021 10:35:04 -0400 Received: by simark.ca (Postfix, from userid 112) id 11C1A1EE14; Fri, 9 Apr 2021 10:35:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 79F721E54D for ; Fri, 9 Apr 2021 10:35:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 129E3398EC05; Fri, 9 Apr 2021 14:35:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 129E3398EC05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617978900; bh=LEz8Zo7FaPbmxH9IpeDnhi2qjq0TXtJskMM6RLdqnHI=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=hdMOflxiMWhChCHS+Q9lOTVD8I/ynbw+531ZWyL4u5LVMx7WBgnrO3z5CUSSHFMDr jEgCNpFQa7BaJnW9nwr/RqI0t/BuVJq62vaowuV8kF4LuPKhcrzcg2QRAqy1pgwAuM HZ18q3Jqwhmv5O2Q2BduGoKObdThIInLeRm44KNA= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 9D8FC385E021 for ; Fri, 9 Apr 2021 14:34:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9D8FC385E021 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 139EYnO3011188 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Apr 2021 10:34:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 139EYnO3011188 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1F4C61E54D; Fri, 9 Apr 2021 10:34:49 -0400 (EDT) Subject: Re: [PATCH] was Re: [PATCH 2/3] [delete] Not-so-harmless spurious call to `wait4` To: Dominique Quatravaux , "gdb-patches@sourceware.org" References: <20210408191449.27434-1-dominique.quatravaux@epfl.ch> <20210408191449.27434-2-dominique.quatravaux@epfl.ch> <133F84AF-3B74-47B1-BEA2-830151901ADE@epfl.ch> Message-ID: <15b36e20-0ff0-6678-cce4-65782ed450e7@polymtl.ca> Date: Fri, 9 Apr 2021 10:34:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <133F84AF-3B74-47B1-BEA2-830151901ADE@epfl.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 9 Apr 2021 14:34:49 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-04-08 4:25 p.m., Dominique Quatravaux wrote:> > >> Le 8 avr. 2021 à 21:26, Simon Marchi > a écrit : >> >> Can you please explain in the commit message what harm >> that wait4 call does and why we want to remove it? > > In trying to make a better case in the commit message, I found that swapping the two patches around made more sense. Here is an updated, rebased, single patch (working under the assumption that the other two will be merged first): > > From 5c3756e9eb0342b1a5a23bcb54d5b8317743ce0d Mon Sep 17 00:00:00 2001 > From: Dominique Quatravaux > > Date: Thu, 8 Apr 2021 21:35:57 +0200 > Subject: [PATCH] [delete] not-so-harmless spurious call to `wait4` > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this > code will typically wait4() a second time on the same process that was > already wait4()'d a few lines above. While this used to be > harmless/idempotent (when we assumed that the process already exited), > this now causes a deadlock in the WIFSTOPPED case. > > The early (~2019) history of bug #24069 cautiously suggests to use > WNOHANG instead of outright deleting the call. However, tests on the > current version of Darwin (Big Sur) demonstrate that gdb runs just > fine without a redundant call to wait4(), as would be expected. > Notwithstanding the debatable value of conserving bug compatibility > with an OS release that is more than a decade old, there is scant > evidence of what that double-wait4() was supposed to achieve in the > first place Thanks, this looks good. If we had more contributors for macOS, especially some that cared about old macOS versions, we could aim at supporting many versions back. But given the current state, it's perfectly reasonable to aim at making GDB work well for the latest version. - A cursory investigation with `git blame` pinpoints > commits bb00b29d7802 and a80b95ba67e2 from the 2008-2009 era, but > fails to answer the “why” question conclusively. Yes, the commits that predate the usage of git don't have the patch message / rationale that people sent along with the patch, it just wasn't recorded in CVS. You can always dig into into the mailing list. a80b95ba67e2: https://pi.simark.ca/gdb-patches/F1826DD8-CC0F-4FF1-BC47-3F2ACBB42909@adacore.com/ bb00b29d7802: https://pi.simark.ca/gdb-patches/20090319141746.GA81236@ulanbator.act-europe.fr/ Although there isn't more details about the bit you are removing. So let's just wait until we hear back from the FSF about your copyright assignment, and then we can merge all of this. Note that we currently require contributions to include ChangeLog entries: https://sourceware.org/gdb/wiki/ContributionChecklist#Properly_Formatted_GNU_ChangeLog I don't mind for this time, the patches are small enough that I can write them when merging. We are also discussing whether we keep using those, so it may or may not apply in the future. Simon