Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@adacore.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@adacore.com>
Subject: [pushed] Minor indentation fix in gdb/nat/windows-nat.h
Date: Wed,  2 Sep 2026 09:38:13 -0600	[thread overview]
Message-ID: <20260902153813.3486662-1-tromey@adacore.com> (raw)

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(-)

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

base-commit: bcca68ba491d7d439875fa9b8b4df8adf17a0986
-- 
2.55.0


                 reply	other threads:[~2026-09-02 15:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260902153813.3486662-1-tromey@adacore.com \
    --to=tromey@adacore.com \
    --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