This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Stepping of multithreaded application
>> 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