Re: Multithreaded debugging: strange thread switches

[Vladimir Prus <ghost@cs.msu.su>]

On Tuesday 24 January 2006 17:28, Daniel Jacobowitz wrote:

> > 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", 

Generally speaking if 2 threads execute 10 steps each, they no longer are at 
the same time, because instructions in thread 1 can take one cycle each, 
while instructions in thread can take two cycles each. I'd prefer this 
synchronization logic to be inside my remote part, which is specifialized for 
that task.

> 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.

Is that bug filed in the bug tracker? Should I file it?

> > > 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 

But if I'm looking at Changelog entry, how can I guess the subject of email 
that discusses this change?

> - and the comments in the code.   

But if change is across 10 files, a comment in one of them is not likely to 
give the entire pictire.

- Volodya