[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 09/23] gdbstub: Fix vCont behaviour
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PULL 09/23] gdbstub: Fix vCont behaviour |
Date: |
Sat, 17 Feb 2018 18:00:07 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2018-02-17 14:27, Alex Bennée wrote:
>
> Jan Kiszka <address@hidden> writes:
>
>> On 2018-02-17 09:56, Jan Kiszka wrote:
>>> On 2017-02-16 15:31, Paolo Bonzini wrote:
>>>> From: Claudio Imbrenda <address@hidden>
>>>>
>>>> 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 <address@hidden>
>>>> Message-Id: <address@hidden>
>>>> Signed-off-by: Paolo Bonzini <address@hidden>
>>>> ---
>>>> 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.
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")
With -smp 1, check_break succeeds.
Jan
signature.asc
Description: OpenPGP digital signature