Re: Multithreaded debugging: strange thread switches

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

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?

> > "Hc2", and in infrun.c, function prepare_to_proceed, I see this:
> >
> >
> >  if (!ptid_equal (wait_ptid, minus_one_ptid)
> >       && !ptid_equal (inferior_ptid, wait_ptid))
> >     {
> >       /* Switched over from WAIT_PID.  */
> >       CORE_ADDR wait_pc = read_pc_pid (wait_ptid);
> >
> >       if (wait_pc != read_pc ())
> > 	{
> > 	  /* Switch back to WAIT_PID thread.  */
> > 	  inferior_ptid = wait_ptid;
> >
> > 	  /* FIXME: This stuff came from switch_to_thread() in
> > 	     thread.c (which should probably be a public function).  */
> > 	  flush_cached_frames ();
> > 	  registers_changed ();
> > 	  stop_pc = wait_pc;
> > 	  select_frame (get_current_frame ());
> > 	}
> >
> > Can somebody explain the reason for this explicit switch back to
> > "wait_ptid"?
>
> I have no idea, but if you remove it you're going to bust the bit below
> that steps over breakpoints, and then GDB will really get unhappy.
> Maybe we can adjust that block of code, though.  See the comment in
> proceed():
>
>   /* In a multi-threaded task we may select another thread
>      and then continue or step.
>
>      But if the old thread was stopped at a breakpoint, it
>      will immediately cause another breakpoint stop without
>      any execution (i.e. it will report a breakpoint hit
>      incorrectly).  So we must step over it first.
>
>      prepare_to_proceed checks the current thread against the thread
>      that reported the most recent event.  If a step-over is required
>      it returns TRUE and sets the current thread to the old thread. */

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

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

> Previously the thread would only be switched if (SIGTRAP && breakpoint
> here).  Now it's switched if (SIGTRAP || SIGINT) and then we
> single-step if (breakpoint here).  Which doesn't make much sense.

I've tried to revert that patch and rerun the testsuite, and got quite a bunch 
of extra errors. I'll look deeper later.

- Volodya