Re: kgdb with bhyve -G : cannot set debug.kdb.current=gdb

> On Fri, Jun 06, 2025 at 05:35:13PM +0000, jmblqe wrote:
>
>> [...]
>>
>> i am unable to solve the following problem:
>>
>> using kgdb requires the following:
>>
>> # sysctl debug.kdb.current=gdb
>
> This is not required when connecting to the gdb stub in bhyve(8)
> (enabled with the -G flag). In that case, the gdb stub lives in the
> hypervisor, not in the kernel.
>
> debug.kdb.current is for when you're connecting directly to the
> in-kernel gdb stub over the serial console or post-panic network stack
> (see netgdb(4)).
>
>> [...]
>>
>> (i found that it actually is possible to attach with kgdb when debug.kdb.current is empty, but then when i set a breakpoint and reach the breakpoint, there is a panic due to the unhandled breakpoint)
>
> This sounds like a bug in the bhyve gdb stub. Can you share a recipe
> for how you're triggering the panic?

Hello Mark,
Thank you for your message.
so, I understand better now how this works, that GDB is inside bhyve in this case.
because of this I think the problem is that the host that I'm running bhyve from is running 12.4. on this isolated physical machine my upgrade process has been delayed/blocked and also I'm being extremely cautious on some things.
so I will try moving this over to machine with a supported release, and reply again with the results.

however, for reference, here is what I do to trigger this panic.

invoke bhyve, wait for host to boot

> bhyve -A -H -P -G 9040 \
> -s 0:0,hostbridge -s 1:0,lpc \
> -s 2:0,virtio-net,tap40 \
> -s 3:0,virtio-blk,./disk \
> -s 29,fbuf,tcp=192.168.1.1:5940,w=800,h=600 \
> -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
> -l com1,stdio \
> -c 1 -m 1024M $NAME

start kgdb (not from host: this is done from a separate 13.5 VM where I built the VM kernel)
then set a breakpoint (example)

> # kgdb -q ./13-5/amd64.amd64/sys/2025/kernel.debug
> Reading symbols from ./13-5/amd64.amd64/sys/2025/kernel.debug
>
> (kgdb) target remote 192.168.1.1:9040
> (kgdb) break g_disk_access
> Breakpoint 1 at 0xffffffff808c8e41: file /usr/src/13-5/sys/geom/geom_disk.c, line 104.
> (kgdb) target remote 192.168.1.1:9040
> Remote debugging using 192.168.1.1:9040
> 0xffffffff80dbd5ad in cpu_idle_acpi (sbt=42436712) at /usr/src/13-5/sys/x86/x86/cpu_machdep.c:244
> 244 __asm __volatile("sti; hlt");
> (kgdb) cContinuing.

then, trigger the panic on bhyve by hitting the breakpoint:

> root@:~ # less -f /dev/vtbd0
>
> Fatal trap 3: breakpoint instruction fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x20:0xffffffff808c8e42
> stack pointer = 0x28:0xfffffe004a769930
> frame pointer = 0x28:0xfffffe004a769950
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, IOPL = 0
> current process = 868 (less)
> trap number = 3
> panic: breakpoint instruction fault
> cpuid = 0
> time = 1749470846
> KDB: stack backtrace:
> #0 0xffffffff809d7915 at kdb_backtrace+0x65
> #1 0xffffffff8098af42 at vpanic+0x182
> #2 0xffffffff8098adb3 at panic+0x43
> #3 0xffffffff80dfc169 at trap_fatal+0x389
> #4 0xffffffff80dd2c48 at calltrap+0x8
> #5 0xffffffff808ceb37 at g_access+0x1b7
> #6 0xffffffff808c6ae0 at g_dev_open+0xa0
> #7 0xffffffff8081c9b0 at devfs_open+0x140
> #8 0xffffffff80e7d5bd at VOP_OPEN_APV+0x1d
> #9 0xffffffff80a7ff4f at vn_open_vnode+0x1df
> #10 0xffffffff80a7fae4 at vn_open_cred+0x5f4
> #11 0xffffffff80a75abc at openatfp+0x26c
> #12 0xffffffff80a7582d at sys_openat+0x3d
> #13 0xffffffff80dfca45 at amd64_syscall+0x105
> #14 0xffffffff80dd355b at fast_syscall_common+0xf8

however, like you said this GDB is in bhyve, so it sounds like I need to try on a supported bhyve...so I'll try soon on a 13.5 one.

>