Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH v2 08/11] Windows gdb+gdbserver: Decode Cygwin ExitProcess codes
Date: Mon, 25 May 2026 20:18:26 +0100	[thread overview]
Message-ID: <20260525191829.984105-9-pedro@palves.net> (raw)
In-Reply-To: <20260525191829.984105-1-pedro@palves.net>

On native Cygwin, GDB misreports the inferior's exit reason in several
common cases, resulting in several gdb.base/exitsignal.exp failures:

 $ grep FAIL gdb.sum
 FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after SIGSEGV.
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after SIGSEGV
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after restarting the inferior
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after restarting the inferior
 FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit
 FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitcode is one after normal inferior is executed
 FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitsignal is still void after normal inferior is executed
 FAIL: gdb.base/exitsignal.exp: how=attach: normal: continue to exit (the program exited)
 FAIL: gdb.base/exitsignal.exp: how=attach: normal: $_exitcode is one after normal inferior is executed

For example, from gdb.log, the normal exit case:

 ...
 [Thread 14300.0x4214 (id 1) exited with code 1]
 [Thread 14300.0x1b1c (id 4) exited with code 1]
 [Thread 14300.0x1e2c (id 2) exited with code 1]

 Program terminated with signal SIGHUP, Hangup.
 The program no longer exists.
 (gdb) FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit

The program in fact exited normally with code 1.  SIGHUP happens to be
signal 1, and GDB picked the wrong interpretation.

Similarly, for the signal termination case:

 ...
 continue
 Continuing.
 [Thread 4600.0x3104 (id 4) exited with code 2816]
 [Thread 4600.0x2bcc (id 3) exited with code 2816]
 [Thread 4600.0x2f44 (id 1) exited with code 2816]
 [Inferior 1 (process 4600) exited with code 05400]
 (gdb) FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)

Here the inferior died with SIGSEGV, but GDB reported exit decimal
2816 / octal 05400 / hex 0x0B00, which is SIGSEGV swapped into the
high byte of a waitpid exit status.

The problem is that Cygwin waitpid exit status and Windows exit codes
do not have the same encoding, and GDB & GDBserver do not know about
this.

This commit fixes it.  It adds a Cygwin-specific branch to the code
that determines the terminating signal and status of a program.  The
branch for native Windows/MinGW GDB is left intact, no behavior change
there.

The way to decode the exit codes is a little bit tricky, see detailed
comments added by the patch.  To exercise the "raw NTSTATUS error
code" path in windows_process_info::exit_process_to_target_status,
gdb.base/exitsignal.exp is extended to debug a native Windows program
that crashes with a segfault (STATUS_ACCESS_VIOLATION).

With this, gdb.base/exitsignal.exp passes cleanly on Cygwin.

Change-Id: Icaebcc234b71927915c996fd120884604441415b
commit-id: bd0fbb9c
---
 gdb/nat/windows-nat.c                 | 153 +++++++++++++++++++++++++-
 gdb/nat/windows-nat.h                 |  29 +++++
 gdb/testsuite/gdb.base/exitsignal.exp |  32 +++++-
 gdb/windows-nat.c                     |   5 +
 gdbserver/win32-low.cc                |   5 +
 5 files changed, 217 insertions(+), 7 deletions(-)

diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
index 92f9394ca6d..27bc65225cc 100644
--- a/gdb/nat/windows-nat.c
+++ b/gdb/nat/windows-nat.c
@@ -654,6 +654,7 @@ windows_process_info::add_dll (LPVOID load_addr)
 	 at which the DLL was loaded is equal to LOAD_ADDR.  */
       if (!(load_addr != nullptr && mi.lpBaseOfDll != load_addr))
 	{
+	  maybe_note_cygwin1_dll (name);
 	  handle_load_dll (name, mi.lpBaseOfDll);
 	  if (load_addr != nullptr)
 	    return;
@@ -681,7 +682,10 @@ windows_process_info::dll_loaded_event (const DEBUG_EVENT &current_event)
      by enumerating all the DLLs loaded into the inferior, looking for
      one that is loaded at base address = lpBaseOfDll. */
   if (dll_name != nullptr)
-    handle_load_dll (dll_name, event->lpBaseOfDll);
+    {
+      maybe_note_cygwin1_dll (dll_name);
+      handle_load_dll (dll_name, event->lpBaseOfDll);
+    }
   else if (event->lpBaseOfDll != nullptr)
     add_dll (event->lpBaseOfDll);
 }
@@ -694,6 +698,48 @@ windows_process_info::add_all_dlls ()
   add_dll (nullptr);
 }
 
+#ifdef __CYGWIN__
+
+/* See nat/windows-nat.h.  */
+
+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;
+}
+
+/* See nat/windows-nat.h.  */
+
+bool
+inferior_started_by_cygwin (DWORD winpid, bool attaching)
+{
+  /* In the run (non-attach) case this is called early when the
+     inferior has only just reached its first instruction and
+     cygwin1.dll hasn't initialized itself yet -- GDB launched the
+     inferior with raw CreateProcess, not through Cygwin's fork/spawn
+     path, so PID_CYGPARENT is necessarily false, so we can shortcut
+     without calling Cygwin.  */
+  if (!attaching)
+    return false;
+
+  /* Note CW_WINPID_TO_CYGWIN_PID never fails.  It returns a synthetic
+     pid for non-Cygwin or unknown winpids, in which case CW_GETPINFO
+     returns either a pinfo with PID_CYGPARENT unset, or NULL.  */
+  auto cygpid = (pid_t) cygwin_internal (CW_WINPID_TO_CYGWIN_PID, winpid);
+
+  auto *pinfo = (external_pinfo *) cygwin_internal (CW_GETPINFO, cygpid);
+  if (pinfo == nullptr)
+    return false;
+
+  return (pinfo->process_state & PID_CYGPARENT) != 0;
+}
+
+#endif /* __CYGWIN__.  */
+
 /* See nat/windows-nat.h.  */
 
 target_waitstatus
@@ -703,6 +749,110 @@ windows_process_info::exit_process_to_target_status
   DWORD exit_code = info.dwExitCode;
   target_waitstatus tstatus;
 
+#ifdef __CYGWIN__
+  /* A Cygwin parent waiting on a Cygwin child via waitpid doesn't go
+     through GetExitCodeProcess / the Win32 exit code at all.  It
+     reads the child's wait status directly out of the child's Cygwin
+     pinfo (shared memory), set by pinfo::exit in
+     winsup/cygwin/pinfo.cc.  So sys/wait.h macros apply to that value
+     verbatim.
+
+     GDB, however, even though it is itself a Cygwin program, drives
+     its inferiors via the native Win32 debugger API: it spawns them
+     with CreateProcess (DEBUG_PROCESS), not via Cygwin's
+     fork/spawn/posix_spawn, and consumes
+     EXIT_PROCESS_DEBUG_EVENT.dwExitCode from WaitForDebugEvent rather
+     than calling waitpid.  That dwExitCode value comes from the
+     inferior's ExitProcess call.
+
+     What that value means depends on two orthogonal things:
+
+     1. Is the inferior a Cygwin process at all?  If not, dwExitCode
+	is a raw Win32 exit value.
+
+     2. For a Cygwin inferior, was it created through Cygwin's spawn
+	path?
+
+	- If not, cygwin1.dll's pinfo::exit byte-swaps the wait status
+	  on the way out, so that the meaningful exit value lands in
+	  the low byte where native Win32 consumers (cmd.exe's "echo
+	  %errorlevel%", and bare GetExitCodeProcess readers) expect
+	  it.  This is the case for Cygwin inferiors that we run, via
+	  CreateProcess.
+
+	- If yes, cygwin1.dll does not swap.  We see this case if we
+	  attach to an already-running process with a Cygwin parent.
+
+	See winsup/cygwin/pinfo.cc:
+
+	 int exitcode = self->exitcode & 0xffff;
+	 if (!self->cygstarted)
+	   exitcode = ((exitcode & 0xff) << 8) | ((exitcode >> 8) & 0xff);
+	 ...
+	 ExitProcess (exitcode);
+  */
+
+  /* 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;
+    }
+
+  if (!this->cygwin1_dll_loaded)
+    {
+      /* Non-Cygwin inferior: dwExitCode is a raw Win32 exit value.
+	 Limit to 8 bits, like Cygwin does, matching what happens with
+	 Cygwin inferiors.  */
+      tstatus.set_exited (exit_code & 0xff);
+      return tstatus;
+    }
+
+  /* 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.  */
+
+  int wstatus = exit_code & 0xffff;
+  if (!this->started_by_cygwin)
+    wstatus = ((wstatus & 0xff) << 8) | ((wstatus >> 8) & 0xff);
+  if (!WIFSIGNALED (wstatus))
+    tstatus.set_exited (WEXITSTATUS (wstatus));
+  else
+    tstatus.set_signalled (gdb_signal_from_host (WTERMSIG (wstatus)));
+#else
   /* If the exit status looks like a fatal exception, but we don't
      recognize the exception's code, make the original exit status
      value available, to avoid losing information.  */
@@ -712,6 +862,7 @@ windows_process_info::exit_process_to_target_status
     tstatus.set_exited (exit_code);
   else
     tstatus.set_signalled (gdb_signal_from_host (exit_signal));
+#endif
 
   return tstatus;
 }
diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
index d2e6adb4f40..2e4db9832ae 100644
--- a/gdb/nat/windows-nat.h
+++ b/gdb/nat/windows-nat.h
@@ -224,6 +224,23 @@ struct windows_process_info
   DWORD process_id = 0;
   DWORD main_thread_id = 0;
 
+#ifdef __CYGWIN__
+  /* True if the inferior was created through Cygwin's spawn path
+     (i.e., its Cygwin pinfo has PID_CYGPARENT set).  We need this at
+     exit time, but we cache it early when we start debugging the
+     inferior, because by exit time the inferior's Cygwin pinfo may
+     have been torn down (CW_GETPINFO returns NULL).  */
+  bool started_by_cygwin = false;
+
+  /* True if cygwin1.dll is loaded into the inferior.  */
+  bool cygwin1_dll_loaded = false;
+
+  /* If DLL_PATH is cygwin1.dll, set cygwin1_dll_loaded to true.  */
+  void maybe_note_cygwin1_dll (const char *dll_path);
+#else
+  void maybe_note_cygwin1_dll (const char *) {}
+#endif
+
 #ifdef __x86_64__
   /* The target is a WOW64 process */
   bool wow64_process = false;
@@ -353,6 +370,18 @@ struct windows_process_info
   int get_exec_module_filename (char *exe_name_ret, size_t exe_name_max_len);
 };
 
+#ifdef __CYGWIN__
+/* Return true if the process with native Windows pid WINPID was
+   started by a Cygwin parent -- that is, its Cygwin pinfo exists and
+   has PID_CYGPARENT set.  Returns false if the process is not a
+   Cygwin process at all, or if its parent is not a Cygwin process.
+
+   ATTACHING indicates whether GDB is attaching to an already-running
+   inferior (true) or has just launched it via CreateProcess
+   (false).  */
+extern bool inferior_started_by_cygwin (DWORD winpid, bool attaching);
+#endif
+
 /* Return a string version of EVENT_CODE.  */
 
 extern std::string event_code_to_string (DWORD event_code);
diff --git a/gdb/testsuite/gdb.base/exitsignal.exp b/gdb/testsuite/gdb.base/exitsignal.exp
index 7684646b546..348c7a72eff 100644
--- a/gdb/testsuite/gdb.base/exitsignal.exp
+++ b/gdb/testsuite/gdb.base/exitsignal.exp
@@ -37,6 +37,10 @@ set exec2 "normal"
 set srcfile2 ${exec2}.c
 set binfile2 [standard_output_file ${exec2}]
 
+set exec3 "segv-win32"
+set srcfile3 ${exec1}.c
+set binfile3 [standard_output_file ${exec3}]
+
 if { [build_executable "failed to build $exec1" ${exec1} "${srcfile1}" \
 	  {debug}] == -1 } {
     return -1
@@ -47,6 +51,16 @@ if { [build_executable "failed to build $exec2" ${exec2} "${srcfile2}" \
     return -1
 }
 
+# On Cygwin, also build a pure-Win32 segv binary, used to test that
+# GDB extracts the terminating SIGSEGV out of the 0xc0000005
+# (STATUS_ACCESS_VIOLATION) Windows exit code.
+if {[istarget "*-*-cygwin*"]} {
+    if { [build_executable "failed to build $exec3" ${exec3} "${srcfile3}" \
+	      {debug win32}] == -1} {
+	return -1
+    }
+}
+
 # Get the inferior under GDB's control in mode HOW ("run" or
 # "attach"), using BINFILE.  In "attach" mode, spawn the binary and
 # attach to it; in "run" mode, run to main.  In both modes, clear the
@@ -81,14 +95,14 @@ proc teardown {how} {
     }
 }
 
-proc test_signal {how} {
-    clean_restart $::exec1
+proc test_signal {how exec binfile} {
+    clean_restart $exec
 
     # Get the inferior under GDB's control.  But, before, change cwd
     # so the core file ends up in the output directory.
     set_inferior_cwd_to_output_dir
 
-    setup $how $::binfile1
+    setup $how $binfile
 
     # Get the inferior's PID for later.
     set pid [get_inferior_pid]
@@ -106,7 +120,8 @@ proc test_signal {how} {
     gdb_test "continue" "(Thread .*|Program) received signal SIGSEGV.*" \
 	"trigger SIGSEGV"
 
-    if {[istarget "*-*-mingw*"]} {
+    if {[istarget "*-*-mingw*"]
+	|| ([istarget "*-*-cygwin*"] && $binfile == $::binfile3)} {
 	# We're debugging a pure Win32 program with no SEH handler.  The
 	# previous continue caught the first-chance exception.  Now we
 	# catch the second-chance one.
@@ -140,7 +155,7 @@ proc test_signal {how} {
     } else {
 	with_test_prefix "reattach" {
 	    kill_wait_spawned_process $::test_spawn_id
-	    setup $how $::binfile1
+	    setup $how $binfile
 	}
     }
 
@@ -190,9 +205,14 @@ foreach_with_prefix how {"run" "attach"} {
     }
 
     with_test_prefix "signal" {
-	test_signal $how
+	test_signal $how $exec1 $binfile1
     }
     with_test_prefix "normal" {
 	test_normal $how
     }
+    if {[istarget "*-*-cygwin*"]} {
+	with_test_prefix "signal, win32" {
+	    test_signal $how $exec3 $binfile3
+	}
+    }
 }
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 26333238cfa..16269671d95 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1994,6 +1994,11 @@ windows_nat_target::do_initial_windows_stuff (DWORD pid, bool attaching)
      phase, and then process them all in one batch now.  */
   windows_process->add_all_dlls ();
 
+#ifdef __CYGWIN__
+  windows_process->started_by_cygwin
+    = inferior_started_by_cygwin (pid, attaching);
+#endif
+
   windows_process->windows_initialization_done = 1;
   return;
 }
diff --git a/gdbserver/win32-low.cc b/gdbserver/win32-low.cc
index 550994b0bf2..2150045e188 100644
--- a/gdbserver/win32-low.cc
+++ b/gdbserver/win32-low.cc
@@ -368,6 +368,11 @@ do_initial_child_stuff (HANDLE proch, DWORD pid, int attached)
      phase, and then process them all in one batch now.  */
   windows_process.add_all_dlls ();
 
+#ifdef __CYGWIN__
+  windows_process.started_by_cygwin
+    = inferior_started_by_cygwin (pid, attached);
+#endif
+
   windows_process.child_initialization_done = 1;
 }
 
-- 
2.53.0


  parent reply	other threads:[~2026-05-25 19:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25 19:18 [PATCH v2 00/11] Fix a few Cygwin/MinGW problems Pedro Alves
2026-05-25 19:18 ` [PATCH v2 01/11] Adjust gdb.base/exitsignal.exp for MinGW, trigger fault Pedro Alves
2026-05-25 19:18 ` [PATCH v2 02/11] Adjust gdb.base/exitsignal.exp for MinGW, second-chance SIGSEGV Pedro Alves
2026-05-26 11:18   ` Eli Zaretskii
2026-05-27 12:56     ` Pedro Alves
2026-05-25 19:18 ` [PATCH v2 03/11] Adjust gdb.base/exitsignal.exp for MinGW, separate program names Pedro Alves
2026-05-27 21:59   ` Thiago Jung Bauermann
2026-06-12 14:00     ` Pedro Alves
2026-05-25 19:18 ` [PATCH v2 04/11] gdb.base/exitsignal.exp: Exit with non-zero Pedro Alves
2026-05-25 19:18 ` [PATCH v2 05/11] gdb.base/exitsignal.exp: Test attaching too Pedro Alves
2026-05-25 19:18 ` [PATCH v2 06/11] gdb/testsuite: Add mechanism to compile Windows native programs on Cygwin Pedro Alves
2026-05-25 19:18 ` [PATCH v2 07/11] Windows gdb+gdbserver: Share exit status logic Pedro Alves
2026-05-25 19:18 ` Pedro Alves [this message]
2026-05-26 11:31   ` [PATCH v2 08/11] Windows gdb+gdbserver: Decode Cygwin ExitProcess codes Eli Zaretskii
2026-05-27 13:58     ` Pedro Alves
2026-05-27 14:12       ` Eli Zaretskii
2026-05-27 22:00   ` Thiago Jung Bauermann
2026-05-25 19:18 ` [PATCH v2 09/11] Adjust gdb.python/py-events.exp for Cygwin/MinGW, thread IDs Pedro Alves
2026-05-25 19:18 ` [PATCH v2 10/11] Adjust gdb.python/py-events.exp for Cygwin/MinGW, no fork Pedro Alves
2026-05-25 19:18 ` [PATCH v2 11/11] Adjust gdb.python/py-events.exp for Cygwin/MinGW, "info proc" => "inferior" Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260525191829.984105-9-pedro@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox