[PATCH] preventing resuming of threads in gdbserver
Daniel Jacobowitz
drow@false.org
Tue Jan 10 21:39:00 GMT 2006
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
More information about the Gdb-patches
mailing list