cracauer@
Developer
This is 16-current but it is probably the same in 15-betas.
Short story:
When running kgdb over bhyve in a setup that worked 12 months ago in 15-current I can stop and continue the kernel and can step normally with source code display. But a kernel panic is not being caught, it just prints to the console and that is it.
%%
Longer story:
This attaches correctly. The guest is stopped and you can continue in kgdb. Stepping works, source code display works.
But if there is a panic in the guest kernel it is not caught by kgdb. I swear this worked 12 months ago in this environment. I did not use a serial port at the time.
Does that work for anybody else? I'm not sure whether I am looking at a regression here or whether I fatfingered something.
Short story:
When running kgdb over bhyve in a setup that worked 12 months ago in 15-current I can stop and continue the kernel and can step normally with source code display. But a kernel panic is not being caught, it just prints to the console and that is it.
%%
Longer story:
Code:
bhyve \
-G 1234 \
-c 16 -m 16G \
-A -H -P \
-s 0,hostbridge \
-s 1,lpc \
-s 3,virtio-net,tap0 \
-s 4,virtio-blk,root2.raw \
-s 5,virtio-blk,FreeBSD-14.1-RELEASE-amd64-ufs.raw \
-l com1,stdio \
-l com2,/dev/nmdm0B \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
fbdbg
Code:
$ kgdb /var/tmp/kernel.debug
(gdb) target remote localhost:1234
(gdb) add-symbol-file /var/tmp/mac_bsdextended.ko.debug
(gdb) cont
This attaches correctly. The guest is stopped and you can continue in kgdb. Stepping works, source code display works.
But if there is a panic in the guest kernel it is not caught by kgdb. I swear this worked 12 months ago in this environment. I did not use a serial port at the time.
Does that work for anybody else? I'm not sure whether I am looking at a regression here or whether I fatfingered something.