[EXTERNAL] Re: Issue with multiple threads using remote protocol on riscv32

[Denio, Mike]

I realized after I sent the second e-mail that I was overthinking the problem. I thought I was going to have to keep 2 states (a real state and a virtual state being what GDB thinks is the state), but then I realized this really only affects the vCont command, so I isolated the changes to that. I already tracked whether or not I was in an "event", so I wouldn't fire off a second "stop" while processing a previous "stop", and my vCont processing already filtered out threads from wildcards based on previous commands (for example: "s:2;c" would filter thread 2 from the continue). So I just added the bottom 2 lines to the "if" statement below and its working great.

                    if( "wildcard" )
                    {
                        // Wildcard sets all bits not previously set
                        tmask = m_AllMask;
                        tmask &= ~stop_mask;
                        tmask &= ~step_mask;
                        tmask &= ~cont_mask;
                        if( m_InEvent )
                            tmask &= ~m_EvtMask;
                    }

Basically, I adjust the vCont command before I even start executing it, which saved me from modifying the lower level debug processing. The "m_EvtMask" is updated on every "vStopped", so the scenario you outline in your e-mail should still work for me. The only thing that concerns me a bit with this simple approach is the signal numbers. I really don't understand them and have been using 00 for 't', 02 for '^c', and 05 for break point. But this seems problematic when processing is delayed. For example, I send a stop with 05 and then GDB sends a "vCont t" for the same thread. Obviously GDB must accept any signal for a "vCont t" because the stop may have already been sent.

Thanks again for the help.

I do have a small issue dealing with how I am using threads that I may send a separate e-mail about. Its not so much a functional issue as a limitation for which someone may be able to suggest a better solution.

Mike

-----Original Message-----
From: Pedro Alves <pedro@palves.net> 
Sent: Thursday, March 17, 2022 12:52 PM
To: Denio, Mike <miked@ti.com>; gdb@sourceware.org
Subject: Re: [EXTERNAL] Re: Issue with multiple threads using remote protocol on riscv32

On 2022-03-16 15:10, Denio, Mike wrote:
> Ok, thanks. I'll have to think about how I'm going to implement that.
> 
> Is it safe to assume that this only affects the initial event, and that once I see the first  'vStopped', GDB will not interlace more 'vCont' commands?
> 
> For example, say I had 8 newly stopped threads such that GDB will end up calling 'vStopped' 8 times. Is it safe to assume that GDB will not send any new vCont in the middle of sending those 8 vStopped?

Currently, when GDB issues a vStopped, it keeps issuing it until the remote side returns OK, indicating no more pending events.
But I wouldn't trust that that won't ever change.  Imagine at some point we come to the conclusion that it would be better to
batch fetching pending events, so that GDB went on to process the pending events once it fetches some N events out of vStopped,
maybe go on to process events out of some other remote connection / target, and then goes back to fetching another batch
of N events out of the first remote connection, and so forth.