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

[Daniel Jacobowitz <drow at mvista dot com>]

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