This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multithreaded debugging: strange thread switches
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