From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] Clarify infrun thread resumption logic.
Date: Sun, 18 Nov 2007 11:37:00 -0000 [thread overview]
Message-ID: <200711181437.18238.vladimir@codesourcery.com> (raw)
This patch clarifies/comments a bit of infrun logic, and does not
introduce any behaviour change or regressions. OK?
- Volodya
* infrun.c (resume): Clarify logic that
decides if a single thread must be resumed. Add
comments.
---
gdb/infrun.c | 40 +++++++++++++++++++++++++++++++++-------
1 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index cf7aa02..85d889a 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -583,15 +583,41 @@ a command like `return' or `jump' to continue execution."));
resume_ptid = RESUME_ALL; /* Default */
- if ((step || singlestep_breakpoints_inserted_p)
- && (stepping_past_singlestep_breakpoint
- || (!breakpoints_inserted && breakpoint_here_p (read_pc ()))))
+ /* If STEP is set, it's a request to use hardware stepping
+ facilities. But in that case, we should never
+ use singlestep breakpoint. */
+ gdb_assert (!(singlestep_breakpoints_inserted_p && step));
+
+ if (singlestep_breakpoints_inserted_p
+ && stepping_past_singlestep_breakpoint)
{
- /* Stepping past a breakpoint without inserting breakpoints.
- Make sure only the current thread gets to step, so that
- other threads don't sneak past breakpoints while they are
- not inserted. */
+ /* The situation here is as follows. In thread T1 we wanted to
+ single-step. Lacking hardware single-stepping we've
+ set breakpoint at the PC of the next instruction -- call it
+ P. After resuming, we've hit that breakpoint in thread T2.
+ Now we've removed original breakpoint, inserted breakpoint
+ at P+1, and try to step to advance T2 past breakpoint.
+ We need to step only T2, as if T1 is allowed to freely run,
+ it can run past P, and if other threads are allowed to run,
+ they can hit breakpoint at P+1, and nested hits of single-step
+ breakpoints is not something we'd want -- that's complicated
+ to support, and has no value. */
+ resume_ptid = inferior_ptid;
+ }
+ if (step && breakpoint_here_p (read_pc ())
+ && !breakpoint_inserted_here_p (read_pc ()))
+ {
+ /* We're stepping, have breakpoint at PC, and it's
+ not inserted. Most likely, proceed has noticed that
+ we have breakpoint and tries to single-step over it,
+ so that it's not hit. In which case, we need to
+ single-step only this thread, and keep others stopped,
+ as they can miss this breakpoint if allowed to run.
+
+ The current code either has all breakpoints inserted,
+ or all removed, so if we let other threads run,
+ we can actually miss any breakpoint, not the one at PC. */
resume_ptid = inferior_ptid;
}
--
1.5.3.5
next reply other threads:[~2007-11-18 11:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-18 11:37 Vladimir Prus [this message]
2007-11-19 11:41 ` Ulrich Weigand
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=200711181437.18238.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb-patches@sources.redhat.com \
/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