Re: [PATCH v2 08/11] Windows gdb+gdbserver: Decode Cygwin ExitProcess codes

[Eli Zaretskii <eliz@gnu.org>]

> From: Pedro Alves <pedro@palves.net>
> Date: Mon, 25 May 2026 20:18:26 +0100
> 
> +void
> +windows_process_info::maybe_note_cygwin1_dll (const char *dll_path)
> +{
> +  const char *base = dll_path + strlen (dll_path);
> +  while (base > dll_path && base[-1] != '/' && base[-1] != '\\')
> +    base--;
> +  if (strcasecmp (base, "cygwin1.dll") == 0)
> +    cygwin1_dll_loaded = true;
> +}

I wonder if this should also detect the MSYS2 DLL, since (AFAIU) MSYS2
is a fork of Cygwin.  But I don't know what is the status of GDB
support for debugging MSYS2 executables.

> +  /* The inferior may also exit with a raw NTSTATUS error code, e.g.,
> +     STATUS_ACCESS_VIOLATION (0xc0000005), without going through the
> +     pinfo::exit at all -- for example, if the unhandled-exception
> +     filter didn't run, or for processes that don't link cygwin1.dll.
> +     Detect those and map them the same way Cygwin's set_exit_code
> +     does in winsup/cygwin/pinfo.cc.  */
> +  if (exit_code >= 0xc0000000)
> +    {
> +      gdb_signal sig;
> +      switch (exit_code)
> +	{
> +	case EXCEPTION_ACCESS_VIOLATION:
> +	  sig = GDB_SIGNAL_SEGV;
> +	  break;
> +	case EXCEPTION_ILLEGAL_INSTRUCTION:
> +	  sig = GDB_SIGNAL_ILL;
> +	  break;
> +	case STATUS_NO_MEMORY:
> +	  sig = GDB_SIGNAL_BUS;
> +	  break;
> +	case STATUS_CONTROL_C_EXIT:
> +	  sig = GDB_SIGNAL_INT;
> +	  break;
> +	default:
> +	  /* Cygwin maps any other NTSTATUS to exit 127.  */
> +	  tstatus.set_exited (127);
> +	  return tstatus;
> +	}
> +      tstatus.set_signalled (sig);
> +      return tstatus;
> +    }

This seems to be a subset of what windows_status_to_termsig already
does, or thereabouts.  Did you intentionally used separate and
slightly different code, and if so, why?  Perhaps the reason should be
in the commentary?

> +  /* Note: when GDB attaches to a Cygwin inferior and the inferior is
> +     then killed externally (e.g., taskkill /F with exit code 1), GDB
> +     and Cygwin disagree.  Cygwin's parent waitpid reports WIFEXITED,
> +     code=1; GDB reports SIGHUP (signal 1, no swap below because
> +     started_by_cygwin).  Cygwin's parent distinguishes "pinfo::exit
> +     ran" from "didn't run" via the child's wait pipe and only applies
> +     the swap-undo for the former.  GDB has only dwExitCode and can't
> +     tell.  This can't be solved without Cygwin's help.  OTOH, such an
> +     external termination steps out of Cygwin and arguably falls into
> +     undefined-behavior territory, so it is less important than the
> +     other cases.  */

This should be arguably reported to Cygwin developers, but until they
fix this, I wonder whether assuming that SIGHUP is much more rare than
TASKKILL (or any other way of natively killing a program on Windows),
and handle 1 as an exit code rather than a signal, will be more useful
in practice?

Thanks.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>