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
prev parent reply other threads:[~2021-10-21 17:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 9:51 [PATCH] gdbstub: Switch to the thread receiving a signal Pavel Labath
2021-10-12 17:10 ` Pavel Labath
2021-10-15 15:59 ` Alex Bennée
2021-10-19 13:19 ` Pavel Labath
2021-10-19 17:13 ` Alex Bennée
2021-10-19 17:02 ` Alex Bennée
2021-10-19 17:53 ` Pavel Labath
2021-10-19 17:49 ` [PATCH v2] " Pavel Labath
2021-10-20 8:35 ` Alex Bennée
2021-10-20 17:04 ` Pavel Labath
2021-10-20 17:57 ` Alex Bennée
2021-10-21 17:36 ` Pavel Labath [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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525a7948-0e36-9121-960c-579fa25c89df@labath.sk \
--to=pavel@labath.sk \
--cc=alex.bennee@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stanshebs@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 NNTP newsgroup(s).