[PATCH 0/3] Show CONTEXT_EXCEPTION_REQUEST info in "info threads"

[PATCH 0/3] Show CONTEXT_EXCEPTION_REQUEST info in "info threads"

[Pedro Alves]

While looking at gdb.threads/hand-call-in-threads.exp failures on
Cygwin, I noticed that on Windows, if you do an infcall on a thread
that is currently blocked in a syscall (e.g., on
ntdll!ZwWaitForMultipleObjects), the infcall will hang (won't really
run) until the thread returns from the system call on its own.  On
Linux, most system calls are interruptible, so you won't see this
happening.  On Windows however, system calls are NOT interruptible.

If you pause the hung thread with Ctrl-C, you'll see that its (user
space) PC won't have changed, still pointing to the entry to the
function GDB wants to call.

For example (with a simple program that just calls sleep in the main
thread):

 ...
 (gdb) t 2
 [Switching to thread 2 (Thread 15648.0x3d58)]
 #0  0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
 (gdb) p malloc(0)
 * hang, press ctrl-c *
 [New Thread 15648.0x12d4 (id 8)]

 Thread 8 received signal SIGINT, Interrupt.
 [Switching to Thread 15648.0x12d4]
 0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
 ❌️ The program received a signal in another thread while
 making a function call from GDB.
 Evaluation of the expression containing the function
 (malloc(size_t)) will be abandoned.
 When the function is done executing, GDB will silently stop.
 (gdb) info threads
   Id   Target Id                                     Frame
   1    Thread 15648.0x4338 "sleeper"                 main () at sleeper.c:5
   2    Thread 15648.0x3d58                           malloc (size=0) at /usr/src/debug/cygwin-3.6.3-1/winsup/cygwin/mm/malloc_wrapper.cc:85
   3    Thread 15648.0x27e0 "sig"                     0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 15648.0x26f0                           0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 15648.0x49f0                           0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
   7    Thread 15648.0x23b0                           0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
 * 8    Thread 15648.0x12d4                           0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll

Now, I remembered from reading about SuspendThread and
GetThreadContext woes early on while working in the non-stop support,
that there was a way to tell whether the interrupted thread was
running kernel or user space code.  After digging through my
bookmarks, I found it.  It's explained here, in a comment from 2014 on
a blog from 2010:

 https://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html#c5639760895973344002

Other places around the interwebs that I found with
CONTEXT_EXCEPTION_REQUEST references all pointed to that sole
comment...  Microsoft doesn't document these flags, AFAICT, other than
a brief mention here:
https://learn.microsoft.com/en-us/windows/win32/debug/working-with-xstate-context
Still, even Wine supports this, and MinGW headers define the
constants.

This series makes the Windows native target expose that information in
"info threads" extra info, like so:

 (gdb) info threads
   Id   Target Id                                     Frame
   1    Thread 15648.0x4338 "sleeper"                 main () at sleeper.c:5
   2    Thread 15648.0x3d58 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 15648.0x27e0 "sig" (in syscall)        0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 15648.0x26f0 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
 * 5    Thread 15648.0xff8 (in exception)             0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
 (gdb)

Above, we can see that thread 1 is running user space code, threads 2
to 4 are in some system call, and thread 5 raised an exception (a
Ctrl-C).

I could imagine us adding a warning whenever GDB changes register
contents or does an infcall on a thread blocked inside a syscall, or
something like that.  But for now, I'm happy with at least seeing the
info.

For gdb.threads/hand-call-in-threads.exp at least, the testcase runs
the infcall on the wrong thread, leading to the hang situation.  Many
testcases assume that threads 2 and above are the that that test
program spawns, which is incorrect on Windows -- the Cygwin runtime
and Windows spawn a few helper threads, so test program threads start
at 4 or 5.  The runtime threads are usually blocked inside a system
call, so doing an infcall on them will hang.

FWIW, I tried the same situation with Visual Studio, and it doesn't
prevent evaluating the expression -- a dialog pops up saying something
like "evaluating expression", and then after a few seconds it aborts
it.  We already support timing out of infcalls nowadays, except we
default to an infinite timeout, so we're mostly covered.

Pedro Alves (3):
  Windows gdb: Show CONTEXT_EXCEPTION_REQUEST info in "info threads"
  gdb manual: Cygwin => Windows
  Windows gdb: Document "info threads" Windows specifics

 gdb/doc/gdb.texinfo   | 67 ++++++++++++++++++++++++++++++-------------
 gdb/nat/windows-nat.h |  3 +-
 gdb/windows-nat.c     | 22 ++++++++++++++
 3 files changed, 71 insertions(+), 21 deletions(-)


base-commit: 8c0ac471835ec86a67c5b42713d9f138f31e4014
-- 
2.53.0

[PATCH 1/3] Windows gdb: Show CONTEXT_EXCEPTION_REQUEST info in "info threads"

[Pedro Alves]

This patch makes the Windows native target expose
CONTEXT_EXCEPTION_REQUEST information in "info threads" extra info,
like so:

 (gdb) info threads
   Id   Target Id                                     Frame
   1    Thread 15648.0x4338 "sleeper"                 main () at sleeper.c:5
   2    Thread 15648.0x3d58 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 15648.0x27e0 "sig" (in syscall)        0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 15648.0x26f0 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
 * 5    Thread 15648.0xff8 (in exception)             0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
 (gdb)

Above, we can see that thread 1 is running user space code, threads 2
to 4 are in some system call, and thread 5 raised an exception (a
Ctrl-C).

This is useful information to see, as system calls are not
interruptible on Windows.  E.g. an infcall on a thread that is blocked
in a system call will appear to hang, until the system call returns on
its own.

Change-Id: I04221f123eef81d59b5cc1c9fbb298f7a33fa001
commit-id:d93544e4
---
 gdb/nat/windows-nat.h |  3 ++-
 gdb/windows-nat.c     | 22 ++++++++++++++++++++++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
index 52378765438..d66d5ec0ed3 100644
--- a/gdb/nat/windows-nat.h
+++ b/gdb/nat/windows-nat.h
@@ -527,7 +527,8 @@ struct WindowsContext<CONTEXT *>
 				     | CONTEXT_SEGMENTS
 #endif
 				     | CONTEXT_DEBUG_REGISTERS
-				     | CONTEXT_EXTENDED_REGISTERS);
+				     | CONTEXT_EXTENDED_REGISTERS
+				     | CONTEXT_EXCEPTION_REQUEST);
 };
 
 #ifdef __x86_64__
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index a9647e90bb8..d01fbc8e4ba 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -3363,6 +3363,28 @@ windows_nat_target::extra_thread_info (thread_info *info)
 	   || th->last_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
     return "exiting process";
 
+  /* Specifying CONTEXT_EXCEPTION_REQUEST in ContextFlags as input
+     (which we do), asks Windows to report back why the thread entered
+     kernel mode.  If GetThreadContext returns a context with
+     CONTEXT_EXCEPTION_REPORTING set, it means that it understood the
+     request.  */
+  windows_process->fill_thread_context (th);
+  DWORD context_flags = *windows_process->context_flags_ptr (th);
+  if ((context_flags & CONTEXT_EXCEPTION_REPORTING) != 0)
+    {
+      /* The thread was running user space code which raised an
+	 exception, which we intercepted.  */
+      if ((context_flags & CONTEXT_EXCEPTION_ACTIVE) != 0)
+	return "in exception";
+
+      /* The thread was running a system call.  */
+      if ((context_flags & CONTEXT_SERVICE_ACTIVE) != 0)
+	return "in syscall";
+
+      /* Otherwise, the thread was simply suspended while running
+	 user space code.  */
+    }
+
   return nullptr;
 }
 
-- 
2.53.0

[PATCH 2/3] gdb manual: Cygwin => Windows

[Pedro Alves]

The Windows-specific commands are all documented in a section called
"Cygwin native", even though the information there also applies to
native/MinGW GDB.  This is most probably because GDB first had a
Cygwin port before it had a MinGW port, eons ago, and nobody updated
the manual.

This patch fixes it.

Change-Id: Id9788fe2a2c36f4482bd701478f4105df79513bc
commit-id:ebc5fee2
---
 gdb/doc/gdb.texinfo | 50 +++++++++++++++++++++++++++------------------
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index ab0216ff477..29d959e68f7 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -25473,7 +25473,7 @@ configurations.
 * BSD libkvm Interface::        Debugging BSD kernel memory images
 * Process Information::         Process information
 * DJGPP Native::                Features specific to the DJGPP port
-* Cygwin Native::               Features specific to the Cygwin port
+* Windows Native::              Features specific to the Windows port
 * Hurd Native::                 Features specific to @sc{gnu} Hurd
 * Darwin::                      Features specific to Darwin
 * FreeBSD::                     Features specific to FreeBSD
@@ -25886,10 +25886,11 @@ counts of various errors encountered so far.
 @end table
 
 
-@node Cygwin Native
+@node Windows Native
 @subsection Features for Debugging MS Windows PE Executables
 @cindex MS Windows debugging
 @cindex native Cygwin debugging
+@cindex Windows-specific commands
 @cindex Cygwin-specific commands
 
 @value{GDBN} supports native debugging of MS Windows programs, including
@@ -25904,10 +25905,13 @@ supports @kbd{C-@key{BREAK}} as an alternative interrupt key
 sequence, which can be used to interrupt the debuggee even if it
 ignores @kbd{C-c}.
 
-There are various additional Cygwin-specific commands, described in
+There are various additional Windows-specific commands, described in
 this section.  Working with DLLs that have no debugging symbols is
 described in @ref{Non-debug DLL Symbols}.
 
+The following commands are available in all native Windows
+configurations, including Cygwin:
+
 @table @code
 @kindex info w32
 @item info w32
@@ -25956,23 +25960,6 @@ automatically, @code{0} will cause a dialog box with ``OK'' and
 terminate the crashing process (OK) or debug it (Cancel).
 @end itemize
 
-@kindex set cygwin-exceptions
-@cindex debugging the Cygwin DLL
-@cindex Cygwin DLL, debugging
-@item set cygwin-exceptions @var{mode}
-If @var{mode} is @code{on}, @value{GDBN} will break on exceptions that
-happen inside the Cygwin DLL.  If @var{mode} is @code{off},
-@value{GDBN} will delay recognition of exceptions, and may ignore some
-exceptions which seem to be caused by internal Cygwin DLL
-``bookkeeping''.  This option is meant primarily for debugging the
-Cygwin DLL itself; the default value is @code{off} to avoid annoying
-@value{GDBN} users with false @code{SIGSEGV} signals.
-
-@kindex show cygwin-exceptions
-@item show cygwin-exceptions
-Displays whether @value{GDBN} will break on exceptions that happen
-inside the Cygwin DLL itself.
-
 @kindex set new-console
 @item set new-console @var{mode}
 If @var{mode} is @code{on} the debuggee will
@@ -26019,6 +26006,29 @@ debuggee seen by the debugger.
 This boolean value adds debug output concerning debuggee memory reads
 and writes by the debugger.
 
+@end table
+
+@sp 1
+In addition, the following commands are available on Cygwin:
+
+@table @code
+@kindex set cygwin-exceptions
+@cindex debugging the Cygwin DLL
+@cindex Cygwin DLL, debugging
+@item set cygwin-exceptions @var{mode}
+If @var{mode} is @code{on}, @value{GDBN} will break on exceptions that
+happen inside the Cygwin DLL.  If @var{mode} is @code{off},
+@value{GDBN} will delay recognition of exceptions, and may ignore some
+exceptions which seem to be caused by internal Cygwin DLL
+``bookkeeping''.  This option is meant primarily for debugging the
+Cygwin DLL itself; the default value is @code{off} to avoid annoying
+@value{GDBN} users with false @code{SIGSEGV} signals.
+
+@kindex show cygwin-exceptions
+@item show cygwin-exceptions
+Displays whether @value{GDBN} will break on exceptions that happen
+inside the Cygwin DLL itself.
+
 @kindex set shell
 @item set shell
 This boolean values specifies whether the debuggee is called
-- 
2.53.0

[PATCH 3/3] Windows gdb: Document "info threads" Windows specifics

[Pedro Alves]

Document "info threads" Windows specifics in the Windows debugging
features section.

Change-Id: I2123899bb8482381657ffbb4f0cc99f196526623
commit-id:856225ce
---
 gdb/doc/gdb.texinfo | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 29d959e68f7..318299fdd3d 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -25905,6 +25905,23 @@ supports @kbd{C-@key{BREAK}} as an alternative interrupt key
 sequence, which can be used to interrupt the debuggee even if it
 ignores @kbd{C-c}.
 
+The @code{info threads} command displays whether a thread stopped due
+to an exception or whether it stopped while running a system call.
+For example:
+
+@smallexample
+(@value{GDBP}) info threads
+  Id   Target Id                            Frame
+  1    Thread 15648.0x4338                  main () at example.c:5
+  2    Thread 15648.0x3d58 (in syscall)     0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
+* 3    Thread 15648.0x12d4 (in exception)   0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
+@end smallexample
+
+Above we see that thread 2 is blocked inside a system call, thread 3
+stopped for an exception, and thread 1 simply stopped while running
+user space code.  Debug events such as breakpoint traps, single-steps,
+and @samp{Ctrl-C} interruptions are considered exceptions.
+
 There are various additional Windows-specific commands, described in
 this section.  Working with DLLs that have no debugging symbols is
 described in @ref{Non-debug DLL Symbols}.
-- 
2.53.0

Re: [PATCH 1/3] Windows gdb: Show CONTEXT_EXCEPTION_REQUEST info in "info threads"

[Eli Zaretskii]

> From: Pedro Alves <pedro@palves.net>
> Date: Mon,  4 May 2026 18:33:40 +0100
> 
> This patch makes the Windows native target expose
> CONTEXT_EXCEPTION_REQUEST information in "info threads" extra info,
> like so:
> 
>  (gdb) info threads
>    Id   Target Id                                     Frame
>    1    Thread 15648.0x4338 "sleeper"                 main () at sleeper.c:5
>    2    Thread 15648.0x3d58 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
>    3    Thread 15648.0x27e0 "sig" (in syscall)        0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
>    4    Thread 15648.0x26f0 (in syscall)              0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
>  * 5    Thread 15648.0xff8 (in exception)             0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
>  (gdb)
> 
> Above, we can see that thread 1 is running user space code, threads 2
> to 4 are in some system call, and thread 5 raised an exception (a
> Ctrl-C).
> 
> This is useful information to see, as system calls are not
> interruptible on Windows.  E.g. an infcall on a thread that is blocked
> in a system call will appear to hang, until the system call returns on
> its own.
> 
> Change-Id: I04221f123eef81d59b5cc1c9fbb298f7a33fa001
> commit-id:d93544e4
> ---
>  gdb/nat/windows-nat.h |  3 ++-
>  gdb/windows-nat.c     | 22 ++++++++++++++++++++++
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
> index 52378765438..d66d5ec0ed3 100644
> --- a/gdb/nat/windows-nat.h
> +++ b/gdb/nat/windows-nat.h
> @@ -527,7 +527,8 @@ struct WindowsContext<CONTEXT *>
>  				     | CONTEXT_SEGMENTS
>  #endif
>  				     | CONTEXT_DEBUG_REGISTERS
> -				     | CONTEXT_EXTENDED_REGISTERS);
> +				     | CONTEXT_EXTENDED_REGISTERS
> +				     | CONTEXT_EXCEPTION_REQUEST);
>  };
>  
>  #ifdef __x86_64__
> diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
> index a9647e90bb8..d01fbc8e4ba 100644
> --- a/gdb/windows-nat.c
> +++ b/gdb/windows-nat.c
> @@ -3363,6 +3363,28 @@ windows_nat_target::extra_thread_info (thread_info *info)
>  	   || th->last_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
>      return "exiting process";
>  
> +  /* Specifying CONTEXT_EXCEPTION_REQUEST in ContextFlags as input
> +     (which we do), asks Windows to report back why the thread entered
> +     kernel mode.  If GetThreadContext returns a context with
> +     CONTEXT_EXCEPTION_REPORTING set, it means that it understood the
> +     request.  */
> +  windows_process->fill_thread_context (th);
> +  DWORD context_flags = *windows_process->context_flags_ptr (th);
> +  if ((context_flags & CONTEXT_EXCEPTION_REPORTING) != 0)
> +    {
> +      /* The thread was running user space code which raised an
> +	 exception, which we intercepted.  */
> +      if ((context_flags & CONTEXT_EXCEPTION_ACTIVE) != 0)
> +	return "in exception";
> +
> +      /* The thread was running a system call.  */
> +      if ((context_flags & CONTEXT_SERVICE_ACTIVE) != 0)
> +	return "in syscall";
> +
> +      /* Otherwise, the thread was simply suspended while running
> +	 user space code.  */
> +    }
> +
>    return nullptr;
>  }

The CONTEXT_* constants you are adding aren't defined in mingw.org's
MinGW headers.  I'm guessing they were introduced for Vista or
something.  So I think we will need to have their explicit definitions
in nat/windows-nat.h, guarded with #ifndef.

Also, this page:

  https://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html

seems to say (near the end) that XP doesn't support
CONTEXT_EXCEPTION_REQUEST, so maybe this feature should be guarded by
a later Windows version, say 7 or 8.1?

Re: [PATCH 3/3] Windows gdb: Document "info threads" Windows specifics

[Eli Zaretskii]

> From: Pedro Alves <pedro@palves.net>
> Date: Mon,  4 May 2026 18:33:42 +0100
> 
> Document "info threads" Windows specifics in the Windows debugging
> features section.
> 
> Change-Id: I2123899bb8482381657ffbb4f0cc99f196526623
> commit-id:856225ce
> ---
>  gdb/doc/gdb.texinfo | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

Thanks.

> +@smallexample
> +(@value{GDBP}) info threads
> +  Id   Target Id                            Frame
> +  1    Thread 15648.0x4338                  main () at example.c:5
> +  2    Thread 15648.0x3d58 (in syscall)     0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
> +* 3    Thread 15648.0x12d4 (in exception)   0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
> +@end smallexample

Aren't these lines too long even for @smallexample?  Did you try
generating PDF, and if so, did you get "overlong" warnings from TeX?

Otherwise, this is okay.

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

Re: [PATCH 2/3] gdb manual: Cygwin => Windows

[Eli Zaretskii]

> From: Pedro Alves <pedro@palves.net>
> Date: Mon,  4 May 2026 18:33:41 +0100
> 
> The Windows-specific commands are all documented in a section called
> "Cygwin native", even though the information there also applies to
> native/MinGW GDB.  This is most probably because GDB first had a
> Cygwin port before it had a MinGW port, eons ago, and nobody updated
> the manual.
> 
> This patch fixes it.
> 
> Change-Id: Id9788fe2a2c36f4482bd701478f4105df79513bc
> commit-id:ebc5fee2
> ---
>  gdb/doc/gdb.texinfo | 50 +++++++++++++++++++++++++++------------------
>  1 file changed, 30 insertions(+), 20 deletions(-)

Thanks.

> +The following commands are available in all native Windows
> +configurations, including Cygwin:

"Windows native" generally excludes Cygwin, because Cygwin uses a
different runtime.  So maybe instead of saying "all native Windows,
including Cygwin" we should say "all native Windows configuration, and
also Cygwin"?  If you agree with that, then the rest of the text you
added and the section name should also be amended.

> +In addition, the following commands are available on Cygwin:
                                           ^^^^^^^^^^^^^^^^^^^
You mean, "available only when debugging Cygwin programs"?

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

Re: [PATCH 2/3] gdb manual: Cygwin => Windows

[Pedro Alves]

Hi Eli,

On 2026-05-04 20:18, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>> 
>> +The following commands are available in all native Windows
>> +configurations, including Cygwin:
> 
> "Windows native" generally excludes Cygwin, because Cygwin uses a
> different runtime.  

Indeed.

> So maybe instead of saying "all native Windows,
> including Cygwin" we should say "all native Windows configuration, and
> also Cygwin"?  If you agree with that, then the rest of the text you
> added and the section name should also be amended.
> 
>> +In addition, the following commands are available on Cygwin:
>                                            ^^^^^^^^^^^^^^^^^^^
> You mean, "available only when debugging Cygwin programs"?
> 
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
> 
How about this?  It splits the node in two, with cross links.


From aa5501f78061475c9dafd1220a0a8447f6b63913 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Mon, 4 May 2026 17:40:12 +0100
Subject: [PATCH] gdb manual: Cygwin => Windows

The Windows-specific commands are all documented in a section called
"Cygwin native", even though the information there also applies to
native/MinGW GDB.  This is most probably because GDB first had a
Cygwin port before it had a MinGW port, eons ago, and nobody updated
the manual.

This patch fixes it, by renaming the existing "Cygwin Native" node to
"Windows Native", and re-adding a new "Cygwin Native" node with the
Cygwin-specific features moved there.

Change-Id: Id9788fe2a2c36f4482bd701478f4105df79513bc
commit-id: ebc5fee2
---
 gdb/doc/gdb.texinfo | 59 +++++++++++++++++++++++++++++----------------
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index ab0216ff477..f132b8fee21 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -25473,6 +25473,7 @@ configurations.
 * BSD libkvm Interface::        Debugging BSD kernel memory images
 * Process Information::         Process information
 * DJGPP Native::                Features specific to the DJGPP port
+* Windows Native::              Features specific to the Windows port
 * Cygwin Native::               Features specific to the Cygwin port
 * Hurd Native::                 Features specific to @sc{gnu} Hurd
 * Darwin::                      Features specific to Darwin
@@ -25886,15 +25887,18 @@ counts of various errors encountered so far.
 @end table
 
 
-@node Cygwin Native
+@node Windows Native
 @subsection Features for Debugging MS Windows PE Executables
 @cindex MS Windows debugging
-@cindex native Cygwin debugging
-@cindex Cygwin-specific commands
+@cindex native Windows debugging
+@cindex Windows-specific commands
 
 @value{GDBN} supports native debugging of MS Windows programs, including
 DLLs with and without symbolic debugging information.
 
+Unless explicitly stated, the following information is also applicable
+to Cygwin.  @xref{Cygwin Native}, for Cygwin-only features.
+
 @cindex Ctrl-BREAK, MS-Windows
 @cindex interrupt debuggee on MS-Windows
 MS-Windows programs that call @code{SetConsoleMode} to switch off the
@@ -25904,7 +25908,7 @@ supports @kbd{C-@key{BREAK}} as an alternative interrupt key
 sequence, which can be used to interrupt the debuggee even if it
 ignores @kbd{C-c}.
 
-There are various additional Cygwin-specific commands, described in
+There are various additional Windows-specific commands, described in
 this section.  Working with DLLs that have no debugging symbols is
 described in @ref{Non-debug DLL Symbols}.
 
@@ -25956,23 +25960,6 @@ automatically, @code{0} will cause a dialog box with ``OK'' and
 terminate the crashing process (OK) or debug it (Cancel).
 @end itemize
 
-@kindex set cygwin-exceptions
-@cindex debugging the Cygwin DLL
-@cindex Cygwin DLL, debugging
-@item set cygwin-exceptions @var{mode}
-If @var{mode} is @code{on}, @value{GDBN} will break on exceptions that
-happen inside the Cygwin DLL.  If @var{mode} is @code{off},
-@value{GDBN} will delay recognition of exceptions, and may ignore some
-exceptions which seem to be caused by internal Cygwin DLL
-``bookkeeping''.  This option is meant primarily for debugging the
-Cygwin DLL itself; the default value is @code{off} to avoid annoying
-@value{GDBN} users with false @code{SIGSEGV} signals.
-
-@kindex show cygwin-exceptions
-@item show cygwin-exceptions
-Displays whether @value{GDBN} will break on exceptions that happen
-inside the Cygwin DLL itself.
-
 @kindex set new-console
 @item set new-console @var{mode}
 If @var{mode} is @code{on} the debuggee will
@@ -26019,6 +26006,36 @@ debuggee seen by the debugger.
 This boolean value adds debug output concerning debuggee memory reads
 and writes by the debugger.
 
+@end table
+
+@node Cygwin Native
+@subsection Features for Debugging Cygwin Programs
+@cindex native Cygwin debugging
+@cindex Cygwin-specific commands
+
+As Cygwin runs on Windows, the features described in @ref{Windows
+Native} section are also applicable to Cygwin.
+
+In addition, the following commands are available on Cygwin:
+
+@table @code
+@kindex set cygwin-exceptions
+@cindex debugging the Cygwin DLL
+@cindex Cygwin DLL, debugging
+@item set cygwin-exceptions @var{mode}
+If @var{mode} is @code{on}, @value{GDBN} will break on exceptions that
+happen inside the Cygwin DLL.  If @var{mode} is @code{off},
+@value{GDBN} will delay recognition of exceptions, and may ignore some
+exceptions which seem to be caused by internal Cygwin DLL
+``bookkeeping''.  This option is meant primarily for debugging the
+Cygwin DLL itself; the default value is @code{off} to avoid annoying
+@value{GDBN} users with false @code{SIGSEGV} signals.
+
+@kindex show cygwin-exceptions
+@item show cygwin-exceptions
+Displays whether @value{GDBN} will break on exceptions that happen
+inside the Cygwin DLL itself.
+
 @kindex set shell
 @item set shell
 This boolean values specifies whether the debuggee is called

base-commit: 8c0ac471835ec86a67c5b42713d9f138f31e4014
prerequisite-patch-id: 9cbfcc1f25d6c22749699faeb50c2f3ca4632c07
-- 
2.53.0

Re: [PATCH 3/3] Windows gdb: Document "info threads" Windows specifics

[Pedro Alves]

Hi Eli,

On 2026-05-04 20:14, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> +@smallexample
>> +(@value{GDBP}) info threads
>> +  Id   Target Id                            Frame
>> +  1    Thread 15648.0x4338                  main () at example.c:5
>> +  2    Thread 15648.0x3d58 (in syscall)     0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
>> +* 3    Thread 15648.0x12d4 (in exception)   0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
>> +@end smallexample
> 
> Aren't these lines too long even for @smallexample?  Did you try
> generating PDF, and if so, did you get "overlong" warnings from TeX?

Indeed, I hadn't looked at the PDF.  I don't get "overlong" warnings, but the
example does not fit on a PDF page, and is cut on the right hand side.

I'd now trimmed as much as I could and wrapped the text in the "Frame" column.

Let me know if this looks OK to you this way.

> 
> Otherwise, this is okay.
> 
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
> 

From 8855c2fee69ce081cfc5efd3b5b8556a2b3a1317 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Mon, 4 May 2026 17:58:49 +0100
Subject: [PATCH 3/3] Windows gdb: Document "info threads" Windows specifics

Document "info threads" Windows specifics in the Windows debugging
features section.

Change-Id: I2123899bb8482381657ffbb4f0cc99f196526623
commit-id: 856225ce
---
 gdb/doc/gdb.texinfo | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index f132b8fee21..90f142335c3 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -25908,6 +25908,27 @@ supports @kbd{C-@key{BREAK}} as an alternative interrupt key
 sequence, which can be used to interrupt the debuggee even if it
 ignores @kbd{C-c}.
 
+The @code{info threads} command displays whether a thread stopped due
+to an exception or whether it stopped while running a system call.
+For example:
+
+@smallexample
+(@value{GDBP}) info threads
+  Id  Target Id                        Frame
+  1   Thread 123.0x338                 main () at example.c:5
+  2   Thread 123.0xd58 (in syscall)    0x00007ffde37057b4 in
+                                         ntdll!ZwWaitForWorkViaWorkerFactory ()
+                                         from C:/WINDOWS/SYSTEM32/ntdll.dll
+* 3   Thread 123.0x2d4 (in exception)  0x00007ffde00aa464 in
+                                         KERNELBASE!CtrlRoutine ()
+                                         from C:/WINDOWS/System32/KERNELBASE.dll
+@end smallexample
+
+Above we see that thread 2 is blocked inside a system call, thread 3
+stopped for an exception, and thread 1 simply stopped while running
+user space code.  Debug events such as breakpoint traps, single-steps,
+and @samp{Ctrl-C} interruptions are considered exceptions.
+
 There are various additional Windows-specific commands, described in
 this section.  Working with DLLs that have no debugging symbols is
 described in @ref{Non-debug DLL Symbols}.

base-commit: 8c0ac471835ec86a67c5b42713d9f138f31e4014
prerequisite-patch-id: 9cbfcc1f25d6c22749699faeb50c2f3ca4632c07
prerequisite-patch-id: 248f41871a76de97d95de3538d27298cdc9b68ce
-- 
2.53.0

Re: [PATCH 2/3] gdb manual: Cygwin => Windows

[Eli Zaretskii]

> Date: Thu, 7 May 2026 18:42:27 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2026-05-04 20:18, Eli Zaretskii wrote:
> >> From: Pedro Alves <pedro@palves.net>> 
> >> +The following commands are available in all native Windows
> >> +configurations, including Cygwin:
> > 
> > "Windows native" generally excludes Cygwin, because Cygwin uses a
> > different runtime.  
> 
> Indeed.
> 
> > So maybe instead of saying "all native Windows,
> > including Cygwin" we should say "all native Windows configuration, and
> > also Cygwin"?  If you agree with that, then the rest of the text you
> > added and the section name should also be amended.
> > 
> >> +In addition, the following commands are available on Cygwin:
> >                                            ^^^^^^^^^^^^^^^^^^^
> > You mean, "available only when debugging Cygwin programs"?
> > 
> > Reviewed-By: Eli Zaretskii <eliz@gnu.org>
> > 
> How about this?  It splits the node in two, with cross links.

LGTM, thanks.

Re: [PATCH 3/3] Windows gdb: Document "info threads" Windows specifics

[Eli Zaretskii]

> Date: Thu, 7 May 2026 18:59:36 +0100
> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2026-05-04 20:14, Eli Zaretskii wrote:
> >> From: Pedro Alves <pedro@palves.net>
> >> +@smallexample
> >> +(@value{GDBP}) info threads
> >> +  Id   Target Id                            Frame
> >> +  1    Thread 15648.0x4338                  main () at example.c:5
> >> +  2    Thread 15648.0x3d58 (in syscall)     0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
> >> +* 3    Thread 15648.0x12d4 (in exception)   0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll
> >> +@end smallexample
> > 
> > Aren't these lines too long even for @smallexample?  Did you try
> > generating PDF, and if so, did you get "overlong" warnings from TeX?
> 
> Indeed, I hadn't looked at the PDF.  I don't get "overlong" warnings, but the
> example does not fit on a PDF page, and is cut on the right hand side.
> 
> I'd now trimmed as much as I could and wrapped the text in the "Frame" column.
> 
> Let me know if this looks OK to you this way.

This looks OK, thanks.