Re: [PATCH] preventing resuming of threads in gdbserver

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 10, 2006 at 01:19:19PM -0800, Michael Snyder wrote:
> Amit Kale wrote:
> >Hi,
> >
> >gdb lets other threads continue execution during single stepping when 
> >doing a single step in remote mode. This behavior causes thread switches 
> >during step or next commands. Native mode behavior is opposite of it. 
> >Attached patch changes it and makes it similar to native mode.
> 
> Actually, letting other threads continue during single stepping
> is the norm.  It happens on almost all multi-thread gdb targets.

Michael's right.  It sometimes does not obviously manifest on native
targets, depending on the implementation of the native system's
scheduler.

> Indeed, if you don't allow it to happen, you're risking deadlock,
> and certainly changing the program behavior.
> 
> Moreover, a patch that changes the behavior of *all* remote targets
> is going to be challenging to get approved.
> 
> 
> 
> On the other hand, there is a user-setable mode variable
> called "scheduler-locking", which is meant to have the exact
> effect you are looking for.  If you wanted to re-do your patch
> so that it made this change conditionally, under the control of
> that variable, it might be more acceptable.

Take a look at the implementation of scheduler-locking; this should
already work for gdbserver - and there's a testcase for it!

-- 
Daniel Jacobowitz
CodeSourcery