Re: Behaviour of default all-stop mode -- Why no one has replied ?

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 15 June 2009 16:09:44, suresh ds wrote:

> Packet received: T05thread:4;thread:5;thread:6;

I have a feeling that GDB will parse this and end up ignoring
the "thread4;thread5" part, as thread:6 will clobber whatever was
parsed as thread id before.  Implementing a stub means to pass to GDB
what GDB wants to, not what you might think you should pass.  Here,
you want only "T05thread:4", that's it.  In all-stop mode, events
have to be serialized to GDB, so, it doesn't really make sense to
pass more than one status.

> 
> ==>> Well, the stub sitting on thread 4 (default hardware thread) corresponds to gdb here. It also sends the status of other (hardware) threads. Initially, I made thread 4 pass only its status as "$T05thread:4", but no difference.
> 
> Sending packet: $Hc-1#09...Ack
> 
> ==>> Here, gdb asks to resume all threads, '-1' indicating 'all threads'. But I don't resume here, all the threads are still in stopped state. If I resume all the threads here in fact, I don't think it'll matter ?

Sure it does matter.  You're resuming the target when GDB
has *not* told you to.  'H' is, and I quote:

"Set thread for subsequent operations".  It just selects the threads,
doesn't resume them.  In any case, if you implement vCont, you won't
see GDB sending Hc appart from this initial one.  You can safely
ignore this, as the vCont packet is stateless.


> ==>> The stub on ht4 (hardware thread 4), has reported three threads, 4, 5, and 6 to gdb; And, gdb has switched to the last reported thread here.

Right, in all-stop mode, GDB always switches the general thread to
to the thread that reported the event, and (this is important) assumes that
the stub has also switched the general thread accordingly.

> ==>> At this point, gdb is made aware that there are three threads waiting to be debugged; 

> Already, the presence of these threads were also indicated when the stub on the default thread sent the status of all the threads. 

Well, you think it has, but it hasn't.  Those extra statuses are just ignored.

> 
> (rmios-gdb)c
> Continuing.
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S;t;T
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> 
> ==>> In default all-stop mode, when you do continue, all threads should continue, correct ? According to our discussions so far (read mails below), gdb will indicate through vCont, which threads it wants to resume. But here, it does not indicate. So, which thread should I resume ? Actually, I resumed the default thread (4). Should the stub resume all the threads even though it has not received any thread no. ?

I already pointed out what should happen here.  Pasting again:

> `vCont[;action[:thread-id]]...'
>      Resume the inferior, specifying different actions for each thread.
>      If an action is specified with no thread-id, then it is applied to any
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      threads that don't have a specific action specified;
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

So, "vCont;c" reads: action == 'c'ontinue; no thread-id specified, and no
other threads have a specific action specified --> means that
action "continue" is applied to all threads.

In other words:

 vCont;c --> continue all threads

 vCont;c:1 --> continue just thread 1

 vCont;s:1;c --> step thread 1, continue all others

 vCont;s:1 --> step thread 1, leaving all others stopped.

> 
> Now, this is without any breakpoints set. Even if I set a breakpoint and continue, it only continues the 'current' thread. I typically expect something like this from gdb. "$vCont;c:4;c:5;blahblah". 

How can you "typically" expect something from the protocol you're just
learning is mystifying to me.  ;-)

> After thread 4 hits the breakpoint, then I switch to some other thread,say 5, and continue, gdb still sends packets only to continue thread 4; Thread 5 does not move at all. In other words, switching to any thread does not make gdb to send packets in that thread context (which I've complained earlier). 
> 
> I tried 'thread-specific breakpoints', and 'thread apply', but to no avail. Forget breakpoint setting; First of all, when I continue from one thread, why gdb is not issuing packets to resume all the threads? Is this not the expected behaviour in default all-stop mode ? In our earlier discussions, you have mentioned that that stub itself should not resume all the threads and that the gdb will indicate that through vCont packets, which is not happening here.

It is.  You have to learn about the "(gdb) set scheduler-locking" setting
first to understand what GDB wants to resume by default.

(you also have the sources of GDB at your disposal.  You can
make use of it to your advantage!  src/gdb/remote.c is where all the
remote protocol action happens).

-- 
Pedro Alves