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

[Michael Snyder <msnyder at redhat dot com>]

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?