public inbox for
 help / color / mirror / Atom feed
From: "Denio, Mike" <>
To: Pedro Alves <>,
	"" <>
Subject: RE: [EXTERNAL] Re: Issue with multiple threads using remote protocol on riscv32
Date: Thu, 17 Mar 2022 19:11:47 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.


-----Original Message-----
From: Pedro Alves <> 
Sent: Thursday, March 17, 2022 12:52 PM
To: Denio, Mike <>;
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.

      reply	other threads:[~2022-03-17 19:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 14:45 Denio, Mike
2022-03-16 14:58 ` Pedro Alves
2022-03-16 15:10   ` [EXTERNAL] " Denio, Mike
2022-03-17 17:52     ` Pedro Alves
2022-03-17 19:11       ` Denio, Mike [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).