Re: Multithreaded debugging: strange thread switches

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jan 24, 2006 at 05:22:47PM +0300, Vladimir Prus wrote:
> On Monday 23 January 2006 18:52, Daniel Jacobowitz wrote:
> 
> > > I'm observing strange behaviour when debugging with gdb using a custom
> > > stub. I have two threads. After connecting, I say "next" several times
> > > and that steps in thread 1. Then I say "thread 2" and "next". Gdb then
> > > stops again in thread 1, not in thread 2 as I'd expected.
> > >
> > > In the remote protocol I see "Hc1" packet after last "next" though I'd
> > > expect
> >
> > This, generally, is part of the problem.  If you want this to work, you
> > need to implement the vCont packet in the stub.  The Hc1 packet is
> > supposed to mean "step only thread 1, leaving thread 2 stopped", and
> > that's not what the gdb "next" command is supposed to map to - that's
> > "step this thread but leave other threads free-running".
> 
> Well, strictly speaking I want "next" to mean "move this thread to next source 
> line, then single-step all other threads until there are at the same time as 
> the current thread". (The remote side is sumulator, so "same time" is 
> well-defined).
> 
> I do not think that vCont can exactly express what I want, so there's always 
> be some difference between what gdb says over remote connection and what I 
> want to be done -- are you sure using vCont will be any better?

Well, GDB doesn't have any command that it expects to have that
behavior.  If you want GDB to do that, I recommend adding such an
interface.  From what I can see, you can get the same effect by "single
step all threads in sync, repeatedly, until this thread reaches the
next source line", which is "vCont;s", or possibly "Hc-1" "s" - not
completely sure about the last one, the documentation suggests that's
right, but I don't know any stub that handles either of these
correctly.

> I see. But after we've single-stepped over breakpoint, will we switch back to 
> the thread where "next" was issued? 

At the moment, no.  This is definitely a bug but it's a pretty nasty
infrun limitation; really that whole subsystem needs some love and
attention.

> > The current code was modified to always select the previous thread
> > in arch-utils.c revision 1.28 in order to support resuming after
> > hitting Control-C:
> >   http://sourceware.org/ml/gdb-patches/2001-05/msg00419.html
> >
> > I can't tell from Jonathan's post what problem he's trying to fix.
> 
> Hmmm, maybe that's a sign that Changelog requirements are suboptimal? Most 
> often, Changelog entries contain lots of details about
> changes to specific functions, but no general overview of the goal of the 
> patch. 

No, the mailing list archives are where this sort of thing is supposed
to live - and the comments in the code.  See the GNU coding standards
and their description of what goes in a changelog entry.  Sometimes
very strange, but that's what we've got to work with.

-- 
Daniel Jacobowitz
CodeSourcery