Re: [10/10] RFC: remove gdb_wait.h

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 15 Nov 2012 13:08:28 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
> 
> > This could break the MinGW build some day, or maybe even today: its
> > definition of WIFSIGNALED and WIFEXITED is inaccurate for Windows.
> > 
> > I say "some day" because it looks like we don't actually use
> > WIFSIGNALED in any file that is compiled on Windows (not sure about
> > WIFEXITED, though).
> 
> In that case, let's be proactive and contribute a patch to gnulib?
> You seem to know what the problem is, so you'd be the best candidate.

With my previous Windows-related contribution to gnulib collecting
dust since January, without any reason (the RM agreed that the code
was correct and should be admitted), why would I bother to submit
another one?

The problem is that the definition of WIFSIGNALED is naive and
incorrect for most Windows programs.  It will cause any program that
does "exit(3);" be considered as exited due to a signal SIGTERM.  And
WIFEXITED, being defined as everything but WIFSIGNALED, is
consequently also incorrect.

The truth is described in the MSDN documentation of
GetExitCodeProcess:

  If the process has terminated and the function succeeds, the status
  returned is one of the following values:

    . The exit value specified in the ExitProcess or TerminateProcess
      function.
    . The return value from the main or WinMain function of the process.
    . The exception value for an unhandled exception that caused the
      process to terminate.

This is how I translated this documentation in my port of GNU
Findutils:

  #define WEXITSTATUS(w)  ((w) & ~0xC0000000)
  #define WIFEXITED(w)    (((w) & 0xC0000000) == 0)
  #define WTERMSIG(w)     (w)
  #define WIFSIGNALED(w)  (((w) & 0xC0000000) != 0)
  #define WIFSTOPPED(w)   (0)

To produce a human-readable description of WTERMSIG, one then needs to
compare its value with the EXCEPTION_* macros defined on winbase.h
header in the w32 API headers, or convert them to Posix signals like
what handle_exception in windows-nat.c and in win32-low.c do.  E.g.,
the value 0xc0000005 means Access Violation, a.k.a. "SIGSEGV".