Date: Wed, 15 Nov 2023 15:55:37 -0800 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: bhyve -G <port> Message-ID: <56b1a46c-db8c-4c0f-8d3e-2cbae7e8015c@FreeBSD.org> In-Reply-To: <234F558A-FB6A-4DE2-A99F-4B4F96C86EF0@iitbombay.org> References: <BD514383-3EE1-495D-818F-15C982994530@iitbombay.org> <f58b372e-fbad-4cf2-bba7-083980719a0c@FreeBSD.org> <234F558A-FB6A-4DE2-A99F-4B4F96C86EF0@iitbombay.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/15/23 3:06 PM, Bakul Shah wrote: > > >> On Nov 15, 2023, at 7:57 AM, John Baldwin <jhb@FreeBSD.org> wrote: >> >> On 10/9/23 5:21 PM, Bakul Shah wrote: >>> Any hints on how to use bhyve's -G <port> option to debug a VM >>> kernel? I can connect to it from gdb with "target remote :<port>" >>> & bhyve stops the VM initially but beyond that I am not sure. >>> Ideally this should work just like an in-circuit-emulator, not >>> requiring anything special in the VM or kernel itself. >> >> step only works on Intel CPUs currently (and is a bit fragile >> anyway due to interrupts firing while you try to step, but that >> happens for me in QEMU as well). Breakpoints should work fine. >> I tend to use 'until' to do stepping (basically stepping via >> temporary breakpoints) when debugging the kernel this way. > > Thanks for your response! > > I can ^C to stop the VM, examine the stack, set breakpoints, > continue etc. but when the breakpoint is hit, kgdb doesn't > regain control -- instead I get the usual > > db> ... > > prompt on the console. I guess I have to set some sysctl for > this? Hmm, no, it shouldn't be breaking into DDB in the guest as the breakpoint exception should be intercepted by the stub and never made visible to the guest. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56b1a46c-db8c-4c0f-8d3e-2cbae7e8015c>