From owner-svn-src-head@freebsd.org Tue May 1 15:31:39 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72EFDFAE634; Tue, 1 May 2018 15:31:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from smtp.freebsd.org (unknown [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C92A7FE23; Tue, 1 May 2018 15:31:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id EA0062A8BE; Tue, 1 May 2018 15:31:38 +0000 (UTC) (envelope-from jhb@freebsd.org) From: John Baldwin To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r333140 - head/usr.sbin/bhyve Date: Tue, 01 May 2018 08:31:28 -0700 Message-ID: <1760664.chHeORK2x4@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <201805011517.w41FHlqI075276@repo.freebsd.org> References: <201805011517.w41FHlqI075276@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:31:39 -0000 On Tuesday, May 01, 2018 03:17:47 PM John Baldwin wrote: > Author: jhb > Date: Tue May 1 15:17:46 2018 > New Revision: 333140 > URL: https://svnweb.freebsd.org/changeset/base/333140 > > Log: > Initial debug server for bhyve. This is definitely "early" work and there are still many things to improve. Note that if you aren't using a file gdb you will need to explicitly set the architecture. Here is an example of booting a VM with -G w1234 which stops at the first instruction: (gdb) set architecture i386:x86-64 The target architecture is assumed to be i386:x86-64 (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0xffffffff8029e9a0 in ?? () (gdb) x/i $pc => 0xffffffff8029e9a0: movw $0x1234,0x472 (gdb) si 0xffffffff8029e9aa in ?? () (gdb) info threads Id Target Id Frame * 1 Thread 1 (vCPU 0) 0xffffffff8029e9aa in ?? () (gdb) c Continuing. ^C[New Thread 2] Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0xffffffff807e0673 in ?? () (gdb) info threads Id Target Id Frame * 1 Thread 1 (vCPU 0) 0xffffffff807e0673 in ?? () 2 Thread 2 (vCPU 1) 0xffffffff807f4fa2 in ?? () (gdb) info registers rax 0x0 0 rbx 0xffffffff80d75400 -2133371904 rcx 0x0 0 rdx 0x40024 262180 rsi 0x1 1 rdi 0xffffffffffffffff -1 rbp 0xfffffe0015282980 0xfffffe0015282980 rsp 0xfffffe0015282970 0xfffffe0015282970 r8 0xfffff80002148000 -8796058124288 r9 0xffffffff80d49090 -2133553008 r10 0xfffff80002148000 -8796058124288 r11 0x1 1 r12 0x0 0 r13 0xfffff80002144000 -8796058140672 r14 0xffffffffffffffff -1 r15 0xffffffff80c30a00 -2134701568 rip 0xffffffff807e0673 0xffffffff807e0673 eflags 0x246 [ PF ZF IF ] cs 0x20 32 ss 0x28 40 ds 0x3b 59 es 0x3b 59 fs 0x13 19 gs 0x28 40 fs_base gs_base (gdb) detach Detaching from program: , Remote target Ending remote debugging. Stepping will only work on Intel CPUs currently and not AMD. (Implementing single-stepping on AMD will prove "interesting" as it will mean raising single-step debug exceptions in the guest and then hiding them from the guest as well as properly shadowing the TF flag in %rflags in the guest and injecting suitable DB# exceptions in the guest if it is also tracing itself, etc.) There is a lot more to work on, but I think this is a useful initial checkpoint. Note that just as with the debug server in QEMU, kgdb does not currently know how to enumerate kernel threads on top of the virtual CPU "threads", so commands like 'tid' and 'proc' will not work if using kgdb. -- John Baldwin