This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Questionable breakpoint stepping code
On Friday 30 November 2007 04:14:13 Joel Brobecker wrote:
> > > I have been away for a week and I still a bit overwhelmed by my email
> > > backlog that caused me to miss the patch. But if Volodya sends me the
> > > patch again, I'll give it a whirl.
> >
> > Thanks Joel!
> > Here's the patch.
>
> Thanks. I don't know why, but somehow, the patch didn't apply cleanly
> to HEAD, so I applied it manually. The results were identical after
> applying and I double-checked that the error never triggered.
Thanks. Michael, do you have any objections to me checking that
patch in (included before for convenience).
- Volodya
* infrun.c (handle_inferior_event): If
we failed to remove breakpoints, error,
don't try to increment PC by hand.
---
gdb/infrun.c | 19 +------------------
1 files changed, 1 insertions(+), 18 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index ad1de6b..b92d0de 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1745,24 +1745,7 @@ handle_inferior_event (struct execution_control_state
*ecs)
process until the child exits (well, okay, not
then either :-) or execs. */
if (remove_status != 0)
- {
- /* FIXME! This is obviously non-portable! */
- write_pc_pid (stop_pc + 4, ecs->ptid);
- /* We need to restart all the threads now,
- * unles we're running in scheduler-locked mode.
- * Use currently_stepping to determine whether to
- * step or continue.
- */
- /* FIXME MVS: is there any reason not to call resume()? */
- if (scheduler_mode == schedlock_on)
- target_resume (ecs->ptid,
- currently_stepping (ecs), TARGET_SIGNAL_0);
- else
- target_resume (RESUME_ALL,
- currently_stepping (ecs), TARGET_SIGNAL_0);
- prepare_to_wait (ecs);
- return;
- }
+ error (_("Cannot step over breakpoint hit in wrong thread"));
else
{ /* Single step */
if (!ptid_equal (inferior_ptid, ecs->ptid))