qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V1] gdbstub: suspended state support


From: Steven Sistare
Subject: Re: [PATCH V1] gdbstub: suspended state support
Date: Thu, 7 Jan 2021 10:05:10 -0500
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]