Re: [PATCH v2] gdbstub: Switch to the thread receiving a signal

From: Pavel Labath <pavel@labath.sk>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: philmd@redhat.com, qemu-devel@nongnu.org, stanshebs@google.com
Subject: Re: [PATCH v2] gdbstub: Switch to the thread receiving a signal
Date: Thu, 21 Oct 2021 19:36:59 +0200	[thread overview]
Message-ID: <525a7948-0e36-9121-960c-579fa25c89df@labath.sk> (raw)
In-Reply-To: <878rynvap3.fsf@linaro.org>

On 20/10/2021 19:57, Alex Bennée wrote:
> 
> Pavel Labath <pavel@labath.sk> writes:
> 
>> On 20/10/2021 10:35, Alex Bennée wrote:
>>> Maybe this is related to the weird output I was seeing above?
>>>
>>
>> Yes, that's definitely related. What's happening is that the qemu does
>> not stop other thread when one of them hits a breakpoint (or stops for
>> any other reason) -- as far as I can tell it does not have any code
>> which would even attempt to do that. This is why you're seeing the
>> output even after the process is purportedly stopped.
>>
>> Things get even more interesting when you have two threads hitting a
>> breakpoint simultaneously. At that point both of them will enter their
>> gdb stubs and attempt to talk to gdb at the same time. As you can
>> imagine, this cannot end well, and eventually the connection will
>> become so messed up that one side just gives up and terminates the
>> link.
>>
>> I am aware of this issue, and I (well, Stan (cc'ed) is, for the most
>> part) looking for a way to fix it. If you have any ideas, we'd very
>> much like to hear them. The way I see it, we need to implement some
>> kind of a "stop the world" mechanism, to stop/interrupt all threads
>> whenever the gdb stub becomes active (and make sure it can handle
>> simultaneous debug events).
> 
> vm_stop(RUN_STATE_PAUSED) should do the trick. We do it elsewhere in
> the gdbstub.
Unfortunately, it seems that vm_stop is only available in softmmu 
targets. Is there a user-mode equivalent by any chance?

> 
>> However, I am don't know enough about qemu
>> internals to tell how to actually go about doing that.
>>
>> My plan was to "get my feet wet" with a simple patch that improves the
>> situation for the case when there are no simultaneous debug events,
>> and eventually hopefully figure out a way how to address the bigger
>> problem.
> 
> Great. Once you've made the changes I think the patch is ready to go in
> and the larger questions can be dealt with later.

Cool. I've sent out v3 of the patch. Let me know if there's anything 
else I need to do.

regards,
Pavel