From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Y+CiAzhJx2C3QAAAWB0awg (envelope-from ) for ; Mon, 14 Jun 2021 08:19:04 -0400 Received: by simark.ca (Postfix, from userid 112) id 0028C1F163; Mon, 14 Jun 2021 08:19:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 DF9821E813 for ; Mon, 14 Jun 2021 08:19:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 67197383F415 for ; Mon, 14 Jun 2021 12:19:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67197383F415 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623673141; bh=m/LKyI9A71kB+C8drXijlwLOgCJcLejBAfUoIUteohU=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=kcFtpxUaleS2CU2kCa0x1rJ1VSCSQFEK25nipxXYNIiOIG0zmMBAL2ne9ujX+Qw55 sI4qpjszjjQd3iRgOKRRvM7ViH2liq1RXZeBqkXQo9Kv2v256XzXc0mJPEwTqO6R+Y 6rQAdJNLTVgD6Ba8cVd7jtizvQcx4tp+2JBaw83Y= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 542233857027 for ; Mon, 14 Jun 2021 12:18:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 542233857027 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42412) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lslXi-0006dr-Qn; Mon, 14 Jun 2021 08:18:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2488 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lslXi-00068S-Ef; Mon, 14 Jun 2021 08:18:14 -0400 Date: Mon, 14 Jun 2021 15:18:09 +0300 Message-Id: <834ke07i7y.fsf@gnu.org> To: Mike Frysinger In-Reply-To: <20210613052519.19005-1-vapier@gentoo.org> (message from Mike Frysinger via Gdb-patches on Sun, 13 Jun 2021 01:25:19 -0400) Subject: Re: [PATCH] gnulib: import sys_wait References: <20210613052519.19005-1-vapier@gentoo.org> 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: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Sun, 13 Jun 2021 01:25:19 -0400 > From: Mike Frysinger via Gdb-patches > > +/* Native Windows API. */ > + > +# include /* for SIGTERM */ > + > +/* The following macros apply to an argument x, that is a status of a process, > + as returned by waitpid() or, equivalently, _cwait() or GetExitCodeProcess(). > + This value is simply an 'int', not composed of bit fields. */ > + > +/* When an unhandled fatal signal terminates a process, the exit code is 3. */ > +# define WIFSIGNALED(x) ((x) == 3) > +# define WIFEXITED(x) ((x) != 3) > +# define WIFSTOPPED(x) 0 > + > +/* The signal that terminated a process is not known posthum. */ > +# define WTERMSIG(x) SIGTERM > + > +# define WEXITSTATUS(x) (x) > + > +/* There are no stopping signals. */ > +# define WSTOPSIG(x) 0 > + > +/* There are no core dumps. */ > +# define WCOREDUMP(x) 0 AFAIU, this conflicts with what we have in gdbsupport/gdb_wait.h and use in windows-nat.c and win32-low.cc. Worse, the Gnulib emulation of this for Windows is (IMNSHO) less useful, since it doesn't support any abnormal termination except the equivalent of SIGABRT (which causes the Windows runtime to exit with status = 3). I tried to convince the Gnulib folks to adopt a more useful emulation, similar to what we have in gdb_wait.h, but AFAIR Bruno Haible rejected the idea. Did you need this Gnulib module because those sims don't use gdbsupport? And if so, is it possible to somehow avoid clashes between this Gnulib module and what we have in gdb_wait.h?