diff mbox series

[pushed] Minor indentation fix in gdb/nat/windows-nat.h

Message ID 20260902153813.3486662-1-tromey@adacore.com
State New
Headers
Series [pushed] Minor indentation fix in gdb/nat/windows-nat.h |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-arm fail Patch failed to apply
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 fail Patch failed to apply

Commit Message

Tom Tromey Sept. 2, 2026, 3:38 p.m. UTC 
  I noticed a comment in gdb/nat/windows-nat.h was not indented
correctly.  This patch fixes it.
---
 gdb/nat/windows-nat.h | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)


base-commit: bcca68ba491d7d439875fa9b8b4df8adf17a0986
diff mbox series

Patch

diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
index 44b628c9bd1..fcdf43e270e 100644
--- a/gdb/nat/windows-nat.h
+++ b/gdb/nat/windows-nat.h
@@ -155,21 +155,20 @@  struct windows_thread_info
      pending stop.  See stop_one_thread.  */
   stopping_kind stopping = SK_NOT_STOPPING;
 
-/* Info about a potential pending stop.
-
-   Sometimes, Windows will report a stop on a thread that has been
-   ostensibly suspended.  We believe what happens here is that two
-   threads hit a breakpoint simultaneously, and the Windows kernel
-   queues the stop events.  However, this can result in the strange
-   effect of trying to single step thread A -- leaving all other
-   threads suspended -- and then seeing a stop in thread B.  To handle
-   this scenario, we queue the "pending" stop here, and then
-   process it once the step has completed.  See PR gdb/22992.
-   If we do have a pending event, its Windows event info is in
-   LAST_EVENT.
-
-   TARGET_WAITKIND_IGNORE if the thread does not have a pending
-   stop.  */
+  /* Info about a potential pending stop.
+
+     Sometimes, Windows will report a stop on a thread that has been
+     ostensibly suspended.  We believe what happens here is that two
+     threads hit a breakpoint simultaneously, and the Windows kernel
+     queues the stop events.  However, this can result in the strange
+     effect of trying to single step thread A -- leaving all other
+     threads suspended -- and then seeing a stop in thread B.  To handle
+     this scenario, we queue the "pending" stop here, and then process
+     it once the step has completed.  See PR gdb/22992.  If we do have a
+     pending event, its Windows event info is in LAST_EVENT.
+
+     TARGET_WAITKIND_IGNORE if the thread does not have a pending
+     stop.  */
   target_waitstatus pending_status;
 
   /* The last Windows event returned by WaitForDebugEvent for this