RFC: Always use at least schedlock_step for software single step targets

RFC: Always use at least schedlock_step for software single step targets

[Daniel Jacobowitz]

This deserves a bit of explanation.  Andrew, this is the same bug I was
telling you about in the hallway at the Summit.  The fix is a bit different,
though.

Our threading test results have always been fairly bad on targets which use
software single step.  One reason was that we didn't properly associate the
single-step breakpoint with a thread.  So if another thread hit it before
the expected one, then that thread would get a SIGTRAP.  Oops.  Worse, if I
set up thread hopping we'd lose the fact that we were originally
single-stepping a different thread, and lose control of the inferior.

I put together a patch to fix both of these.  It was pretty gross, so I'm
not including it here, but it worked.  It had a different problem, however:
we livelock in schedlock.exp because other threads always hit the breakpoint
before the one we're trying to step.  A similar problem was solved in
lin-lwp by an ad-hoc scheduler, if I recall correctly.  I concluded that the
tradeoffs for implementing this sort of scheduler on a remote stub were too
high, and used this patch instead.  If we're inserting a software single
step breakpoint, be sure to resume only one thread.

Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-06-05  Daniel Jacobowitz  <drow@mvista.com>

	* infrun.c (resume): Always assume schedlock_step for
	software single step.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.109
diff -u -p -r1.109 infrun.c
--- infrun.c	7 May 2003 18:35:57 -0000	1.109
+++ infrun.c	5 Jun 2003 14:30:43 -0000
@@ -625,10 +625,11 @@ resume (int step, enum target_signal sig
 	}
 
       if ((scheduler_mode == schedlock_on) ||
-	  (scheduler_mode == schedlock_step &&
-	   (step || singlestep_breakpoints_inserted_p)))
+	  (scheduler_mode == schedlock_step && step)
+	  || singlestep_breakpoints_inserted_p)
 	{
 	  /* User-settable 'scheduler' mode requires solo thread resume. */
+	  /* Software single-step doesn't work right with multiple threads.  */
 	  resume_ptid = inferior_ptid;
 	}
 

Re: RFC: Always use at least schedlock_step for software single step targets

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> This deserves a bit of explanation.  Andrew, this is the same bug I was
> telling you about in the hallway at the Summit.  The fix is a bit different,
> though.
> 
> Our threading test results have always been fairly bad on targets which use
> software single step.  One reason was that we didn't properly associate the
> single-step breakpoint with a thread. 

We didn't?  I thought a single-step breakpoint was always thread-specific?
Pretty sure it used to be...

> So if another thread hit it before
> the expected one, then that thread would get a SIGTRAP.  Oops.  Worse, if I
> set up thread hopping we'd lose the fact that we were originally
> single-stepping a different thread, and lose control of the inferior.
> 
> I put together a patch to fix both of these.  It was pretty gross, so I'm
> not including it here, but it worked.  It had a different problem, however:
> we livelock in schedlock.exp because other threads always hit the breakpoint
> before the one we're trying to step.  A similar problem was solved in
> lin-lwp by an ad-hoc scheduler, if I recall correctly.  I concluded that the
> tradeoffs for implementing this sort of scheduler on a remote stub were too
> high, and used this patch instead.  If we're inserting a software single
> step breakpoint, be sure to resume only one thread.
> 
> Thoughts?

It effectively forces schedlock_step for SSS targets
(but I guess you knew that).  People appear to be very
diverse in their opinion about whether schedlock is the
"right" behavior or the "wrong" one.  You might not see
the behavior that you're trying to debug, if you're only
stepping one thread.

 
> 2003-06-05  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * infrun.c (resume): Always assume schedlock_step for
>         software single step.
> 
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 infrun.c
> --- infrun.c    7 May 2003 18:35:57 -0000       1.109
> +++ infrun.c    5 Jun 2003 14:30:43 -0000
> @@ -625,10 +625,11 @@ resume (int step, enum target_signal sig
>         }
> 
>        if ((scheduler_mode == schedlock_on) ||
> -         (scheduler_mode == schedlock_step &&
> -          (step || singlestep_breakpoints_inserted_p)))
> +         (scheduler_mode == schedlock_step && step)
> +         || singlestep_breakpoints_inserted_p)
>         {
>           /* User-settable 'scheduler' mode requires solo thread resume. */
> +         /* Software single-step doesn't work right with multiple threads.  */
>           resume_ptid = inferior_ptid;
>         }
>

Re: RFC: Always use at least schedlock_step for software single step targets

[Daniel Jacobowitz]

On Thu, Jun 05, 2003 at 11:44:36AM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > This deserves a bit of explanation.  Andrew, this is the same bug I was
> > telling you about in the hallway at the Summit.  The fix is a bit different,
> > though.
> > 
> > Our threading test results have always been fairly bad on targets which use
> > software single step.  One reason was that we didn't properly associate the
> > single-step breakpoint with a thread. 
> 
> We didn't?  I thought a single-step breakpoint was always thread-specific?
> Pretty sure it used to be...

Well, I can't find any trace of it.  For instance, on ARM it is
literally blatted into memory in arm_software_single_step.  Ew.

> > So if another thread hit it before
> > the expected one, then that thread would get a SIGTRAP.  Oops.  Worse, if I
> > set up thread hopping we'd lose the fact that we were originally
> > single-stepping a different thread, and lose control of the inferior.
> > 
> > I put together a patch to fix both of these.  It was pretty gross, so I'm
> > not including it here, but it worked.  It had a different problem, however:
> > we livelock in schedlock.exp because other threads always hit the breakpoint
> > before the one we're trying to step.  A similar problem was solved in
> > lin-lwp by an ad-hoc scheduler, if I recall correctly.  I concluded that the
> > tradeoffs for implementing this sort of scheduler on a remote stub were too
> > high, and used this patch instead.  If we're inserting a software single
> > step breakpoint, be sure to resume only one thread.
> > 
> > Thoughts?
> 
> It effectively forces schedlock_step for SSS targets
> (but I guess you knew that).  People appear to be very
> diverse in their opinion about whether schedlock is the
> "right" behavior or the "wrong" one.  You might not see
> the behavior that you're trying to debug, if you're only
> stepping one thread.

Yeah.  Do you think it's worthwhile to revisit this and investigate an
event scheduler in gdbserver also?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Always use at least schedlock_step for software single step targets

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jun 05, 2003 at 11:44:36AM -0700, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > This deserves a bit of explanation.  Andrew, this is the same bug I was
> > > telling you about in the hallway at the Summit.  The fix is a bit different,
> > > though.
> > >
> > > Our threading test results have always been fairly bad on targets which use
> > > software single step.  One reason was that we didn't properly associate the
> > > single-step breakpoint with a thread.
> >
> > We didn't?  I thought a single-step breakpoint was always thread-specific?
> > Pretty sure it used to be...
> 
> Well, I can't find any trace of it.  For instance, on ARM it is
> literally blatted into memory in arm_software_single_step.  Ew.
> 
> > > So if another thread hit it before
> > > the expected one, then that thread would get a SIGTRAP.  Oops.  Worse, if I
> > > set up thread hopping we'd lose the fact that we were originally
> > > single-stepping a different thread, and lose control of the inferior.
> > >
> > > I put together a patch to fix both of these.  It was pretty gross, so I'm
> > > not including it here, but it worked.  It had a different problem, however:
> > > we livelock in schedlock.exp because other threads always hit the breakpoint
> > > before the one we're trying to step.  A similar problem was solved in
> > > lin-lwp by an ad-hoc scheduler, if I recall correctly.  I concluded that the
> > > tradeoffs for implementing this sort of scheduler on a remote stub were too
> > > high, and used this patch instead.  If we're inserting a software single
> > > step breakpoint, be sure to resume only one thread.
> > >
> > > Thoughts?
> >
> > It effectively forces schedlock_step for SSS targets
> > (but I guess you knew that).  People appear to be very
> > diverse in their opinion about whether schedlock is the
> > "right" behavior or the "wrong" one.  You might not see
> > the behavior that you're trying to debug, if you're only
> > stepping one thread.
> 
> Yeah.  Do you think it's worthwhile to revisit this and investigate an
> event scheduler in gdbserver also?

Dunno -- you seem to be the main person working on gdbserver these days.  ;-)

Schedlock is user-settable.  Maybe the SSS-schedlock behavior that
you want should be user-settable too?  Or maybe SSS targets could
force a default to schedlock_step, and the user could cancel it
if he wanted to?

Re: RFC: Always use at least schedlock_step for software single step targets

[Andrew Cagney]

> It effectively forces schedlock_step for SSS targets
> (but I guess you knew that).  People appear to be very
> diverse in their opinion about whether schedlock is the
> "right" behavior or the "wrong" one.  You might not see
> the behavior that you're trying to debug, if you're only
> stepping one thread.

There are targets for which sched lock almost meaningless, but then, 
hopefully those targets also support hardware single step.

The change looks to be the best option.

Andrew

Re: RFC: Always use at least schedlock_step for software single step targets

[Daniel Jacobowitz]

On Fri, Jun 06, 2003 at 05:36:45PM -0400, Andrew Cagney wrote:
> 
> >It effectively forces schedlock_step for SSS targets
> >(but I guess you knew that).  People appear to be very
> >diverse in their opinion about whether schedlock is the
> >"right" behavior or the "wrong" one.  You might not see
> >the behavior that you're trying to debug, if you're only
> >stepping one thread.
> 
> There are targets for which sched lock almost meaningless, but then, 
> hopefully those targets also support hardware single step.
> 
> The change looks to be the best option.

I think I'm going to revisit an event scheduler in gdbserver to fix the
livelock, before I commit this.  Since I'd rather schedlock worked on
mips-linux.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer