This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Always use at least schedlock_step for software single step targets
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 Jun 2003 14:47:23 -0400
- Subject: Re: RFC: Always use at least schedlock_step for software single step targets
- References: <20030605143728.GA31355@nevyn.them.org> <3EDF8F94.27C60521@redhat.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