* [RFA] Clarify infrun thread resumption logic.
@ 2007-11-18 11:37 Vladimir Prus
2007-11-19 11:41 ` Ulrich Weigand
0 siblings, 1 reply; 2+ messages in thread
From: Vladimir Prus @ 2007-11-18 11:37 UTC (permalink / raw)
To: gdb-patches
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFA] Clarify infrun thread resumption logic.
2007-11-18 11:37 [RFA] Clarify infrun thread resumption logic Vladimir Prus
@ 2007-11-19 11:41 ` Ulrich Weigand
0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Weigand @ 2007-11-19 11:41 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
Vladimir Prus wrote:
> * infrun.c (resume): Clarify logic that
> decides if a single thread must be resumed. Add
> comments.
This is OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-11-19 11:41 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-18 11:37 [RFA] Clarify infrun thread resumption logic Vladimir Prus
2007-11-19 11:41 ` Ulrich Weigand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox