[PULL,09/23] gdbstub: Fix vCont behaviour

Commit Message

Jan Kiszka Feb. 17, 2018, 5 p.m. UTC

On 2018-02-17 14:27, Alex Bennée wrote:
> 
> Jan Kiszka <[e-mail]> writes:
> 
>> On 2018-02-17 09:56, Jan Kiszka wrote:
>>> On 2017-02-16 15:31, Paolo Bonzini wrote:
>>>> From: Claudio Imbrenda <[e-mail]>
>>>>
>>>> When GDB issues a "vCont", QEMU was not handling it correctly when
>>>> multiple VCPUs are active.
>>>> For vCont, for each thread (VCPU), it can be specified whether to
>>>> single step, continue or stop that thread. The default is to stop a
>>>> thread.
>>>> However, when (for example) "vCont;s:2" is issued, all VCPUs continue
>>>> to run, although all but VCPU nr 2 are to be stopped.
>>>>
>>>> This patch completely rewrites the vCont parsing code.
>>>>
>>>> Please note that this improvement only works in system emulation mode,
>>>> when in userspace emulation mode the old behaviour is preserved.
>>>>
>>>> Signed-off-by: Claudio Imbrenda <[e-mail]>
>>>> Message-Id: <[e-mail]>
>>>> Signed-off-by: Paolo Bonzini <[e-mail]>
>>>> ---
>>>>  gdbstub.c | 209 ++++++++++++++++++++++++++++++++++++++++++++++++--------------
>>>>  1 file changed, 162 insertions(+), 47 deletions(-)
>>>>
> <snip>
>>>
>>> Seems like no one is doing guest debugging with kvm on x86 except me,
>>> and I'm only doing it too infrequently now: This one broke that use case
>>> for SMP guests long ago. How was it tested?
>>>
>>> To reproduce the bug: set up an x86-64 guest kernel with > 1 core, break
>>> on some prominent syscall entry (e.g. sys_execve), continue the guest on
>>> hit and it will quickly lock up, even after disabling the breakpoint
>>> again. Kernel version doesn't matter (was my first guess), gdb is
>>> 7.7.50.20140604-cvs (OpenSUSE) here.
> 
> I thought I fixed this with 5a6a1ad181c658b810041d852b290ac836965aca
> 
> FWIW I do periodically test ARM TCG and KVM guest debug using:
> 
>   tests/guest-debug/test-gdbstub.py
> 
> But we are missing a nice integration to get an appropriate guest image
> to automate this process. If we can fix that we should be able to turn
> on the test as part of make check.
> 

If that test above is extended with more interesting setups, that should
be enough. E.g., you can reproduce this issue by running qemu with -smp
4 and the following test modifications.



With -smp 1, check_break succeeds.

Jan

Patch

diff --git a/tests/guest-debug/test-gdbstub.py b/tests/guest-debug/test-gdbstub.py
index 31ba6c943a..a55782fa9a 100644
--- a/tests/guest-debug/test-gdbstub.py
+++ b/tests/guest-debug/test-gdbstub.py
@@ -15,6 +15,7 @@  def report(cond, msg):
         print ("PASS: %s" % (msg))
     else:
         print ("FAIL: %s" % (msg))
+        global failcount
         failcount += 1
 
 
@@ -33,6 +34,7 @@  def check_break(sym_name):
     bp = gdb.Breakpoint(sym_name)
 
     gdb.execute("c")
+    gdb.execute("c 100")
 
     # hopefully we came back
     end_pc = gdb.parse_and_eval('$pc')
@@ -138,12 +140,12 @@  def run_test():
     # Can't set this up until we are in the kernel proper
     # if we make it to run_init_process we've over-run and
     # one of the tests failed
-    print ("Setup catch-all for run_init_process")
-    cbp = CatchBreakpoint("run_init_process")
-    cpb2 = CatchBreakpoint("try_to_run_init_process")
+    #print ("Setup catch-all for run_init_process")
+    #cbp = CatchBreakpoint("run_init_process")
+    #cpb2 = CatchBreakpoint("try_to_run_init_process")
 
     print ("Checking Normal breakpoint works")
-    break_ok = check_break("wait_for_completion")
+    break_ok = check_break("SyS_execve")
     report(break_ok, "break @ wait_for_completion")
 
     print ("Checking watchpoint works")