Re: Stepping of multithreaded application

[Tomas Martinec <fyzmat@gmail.com>]

>> That is not supported in the virtual machine
>> and the machine responds so. I believe not supporting the Hc0 command
>> is not wrong for the virtual machine.
>
> IMO, it's wrong.  But I don't think it'd make a difference, unless
> the target gives preference to the already/previously selected
> Hg/c thread.

> In any case, you should really teach your VM about the vCont
> packet instead of 'Hc'/'s'/'c'.

I will implement both the Hc0 and vCont in the virtual machine. But at
first I will try to make just the Hc/s/c commands working.

> Please try the patch below.  It's "any_thread_ptid" that causes "Hc0".
> If we're stepping, obviously we need to step the correct thread, not
> a random one.  I don't really understand how this hasn't been a
> problem before.

There was another problem after applying the patch. The GDB resumed
the thread 1 after the thread 3 stepped. I think I have made a fix:

--- infrun_old.c	2010-08-31 21:31:23.000000000 +0200
+++ infrun.c	2011-05-12 12:20:15.000000000 +0200
@@ -3513,6 +3513,8 @@
 	      singlestep_breakpoints_inserted_p = 0;
 	    }

+	  ecs->event_thread->trap_expected = 0;
+
 	  /* Note: We do not call context_switch at this point, as the
 	     context is already set up for stepping the original thread.  */
 	  switch_to_thread (deferred_step_ptid);

The trap_expected flag of the thread 1 was not cleared after the step
of thread 1. Therefore the code has run into the following branch
during step handling of the thread 3:

infrun.c: line 4182

  /* In all-stop mode, if we're currently stepping but have stopped in
     some other thread, we need to switch back to the stepped thread.  */
  if (!non_stop)
    {
      struct thread_info *tp;

      tp = iterate_over_threads (currently_stepping_or_nexting_callback,
				 ecs->event_thread);
      if (tp)
	{
              // this branch is done, which is wrong; it is done,
because the thread 1
              // has trap_expected set and therefore the thread is
considered to be stepping
              //
              // the thread 1 is resumed in this branch; in my case
the thread 3 never finishes stepping

The debugging seems to be fine after applying my fix. Still I think
somebody more familiar with the GDB should review it.

Tomas