From: Steven Sistare <steven.sistare@oracle.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH V1] gdbstub: suspended state support
Date: Thu, 7 Jan 2021 10:05:10 -0500 [thread overview]
Message-ID: <363fd686-aa5f-60ea-f330-1213a32ca031@oracle.com> (raw)
In-Reply-To: <87h7ns2a24.fsf@linaro.org>
On 1/7/2021 7:40 AM, Alex Bennée wrote:
> Steve Sistare <steven.sistare@oracle.com> writes:
>
>> Modify the gdb server so a continue command appears to resume execution
>> when in RUN_STATE_SUSPENDED. Do not print the next gdb prompt, but do not
>> actually resume instruction fetch. While in this "fake" running mode, a
>> ctrl-C returns the user to the gdb prompt.
>
> What exactly is the purpose of this? To hide the details of the runstate
> as controlled by the user? I wouldn't expect someone using gdb debugging
> not to also have control of the HMP/QMP interface.
Without this fix, a user that attaches gdb to a suspended guest breaks the
guest. The state is RUN_STATE_SUSPENDED. After attaching gdb and typing
continue or quit, qemu transitions to RUN_STATE_RUNNING (wrong) and the
guest continues execution (wrong). The guest loops polling on an acpi port,
deep in a call stack under acpi_suspend_enter(). Sending a system_wakeup
request via qmp or hmp fails with the message "Error: Unable to wake up:
guest is not in suspended state".
With the fix, the state remains RUN_STATE_SUSPENDED throughout, until the
system_wakeup request, and the guest pc does not change. gdb interprets
RUN_STATE_SUSPENDED as "target is running", without causing instruction
fetch to resume.
If you are satisfied, I will add this explanation to the commit message.
- Steve
>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
>> ---
>> gdbstub.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdbstub.c b/gdbstub.c
>> index f3a318c..2f0d9ff 100644
>> --- a/gdbstub.c
>> +++ b/gdbstub.c
>> @@ -461,7 +461,9 @@ static inline void gdb_continue(void)
>> #else
>> if (!runstate_needs_reset()) {
>> trace_gdbstub_op_continue();
>> - vm_start();
>> + if (!runstate_check(RUN_STATE_SUSPENDED)) {
>> + vm_start();
>> + }
>> }
>> #endif
>> }
>> @@ -490,7 +492,7 @@ static int gdb_continue_partial(char *newstates)
>> int flag = 0;
>>
>> if (!runstate_needs_reset()) {
>> - if (vm_prepare_start()) {
>> + if (!runstate_check(RUN_STATE_SUSPENDED) && vm_prepare_start()) {
>> return 0;
>> }
>>
>> @@ -2835,6 +2837,9 @@ static void gdb_read_byte(uint8_t ch)
>> /* when the CPU is running, we cannot do anything except stop
>> it when receiving a char */
>> vm_stop(RUN_STATE_PAUSED);
>> + } else if (runstate_check(RUN_STATE_SUSPENDED) && ch == 3) {
>> + /* Received ctrl-c from gdb */
>> + gdb_vm_state_change(0, 0, RUN_STATE_PAUSED);
>> } else
>> #endif
>> {
>> @@ -3282,6 +3287,8 @@ static void gdb_sigterm_handler(int signal)
>> {
>> if (runstate_is_running()) {
>> vm_stop(RUN_STATE_PAUSED);
>> + } else if (runstate_check(RUN_STATE_SUSPENDED)) {
>> + gdb_vm_state_change(0, 0, RUN_STATE_PAUSED);
>> }
>> }
>> #endif
>
>
next prev parent reply other threads:[~2021-01-07 15:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 20:10 [PATCH V1] gdbstub: suspended state support Steve Sistare
2021-01-07 12:40 ` Alex Bennée
2021-01-07 15:05 ` Steven Sistare [this message]
2021-01-07 16:02 ` Alex Bennée
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=363fd686-aa5f-60ea-f330-1213a32ca031@oracle.com \
--to=steven.sistare@oracle.com \
--cc=alex.bennee@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).