Re: [PATCH] gnulib: import sys_wait

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

> Date: Sun, 13 Jun 2021 01:25:19 -0400
> From: Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>
> 
> +/* Native Windows API.  */
> +
> +# include <signal.h> /* 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?