December 6, 2019 at 23:21 #26784
As a workaround, unless you are debugging drivers for hardware that cannot be virtualised, please consider using VM snapshots as a way of recovering from file system corruption.
OK, so I took your advice and put the entire target in a snapshotted QEMU VM.
I had to choose something else than VMware and VirtualBox (VMs that VK declares support for) because they only support the x86 architectures for the guest/target systems and QEMU supports ARM, MIPS, Alpha, CRIS, LM32, M68k, MicroBlaze, OpenRisc32, PowerPC, S/390, SH4, SPARC 32/64, Unicore32, Xtensa, x86, x86-64.
My debugees usually run on ARM, MIPS CPUs, so I really could not have used VMware nor VirtualBox. I am using Debian 9 or 10 compiled for these plattforms.
QUESTION: How to reliably debug Debian (ARM) running in QEMU with VisualKernel?
I am running QEMU with the command line listed below.
Notice that the option:
hostfwd=tcp:127.0.0.1:10022-192.168.0.15:22forwards the SSH port 10022 on the localhost (where VirtualKernel is running) to the IP address of the guest/target Debian Linux (ARM) running inside the QEMU VM. That is why VK communicates with the target via email@example.com:10022.
Also notice, that the option
-device virtio-net-devicemeans that the network adapter which the guest/target Debian sees and talks to, is a virtio adapter.
Do I need to forward any other ports to get the debugging working with QEMU or must I play with virtual UART ports, or something else entirely ?
qemu-system-arm -M virt
-drive if=none,file=hda.qcow2,format=qcow2,id=hd -device virtio-blk-device,drive=hd
-netdev user,id=mynet,restrict=off,net=192.168.0.0/24,hostfwd=tcp:127.0.0.1:10022-192.168.0.15:22 -device virtio-net-device,netdev=mynet
December 6, 2019 at 23:26 #26785
- This topic was modified 1 year, 5 months ago by Goerge255.
Sorry, we absolutely do not support Qemu. It is extremely unreliable and difficult to configure. Please try using VMWare instead.December 6, 2019 at 23:37 #26787
Please try using VMWare instead.
But how ?
VMware does not support ARM nor MIPS CPUs !!!
December 6, 2019 at 23:53 #26791
- This reply was modified 1 year, 5 months ago by Goerge255.
Thanks for clarifying this. In that case, indeed QEmu could one of the best bets, although configuring it would be non-trivial.
Generally, Qemu supports the gdb stub mode similar to VWMare, so we would advise the following configuration:
- Forward SSH port from the target to 10022 or any other port and specify “localhost:10022” as the host name in VisualKernel.
- Enable the gdb stub mode in Qemu and use the “custom” mode in VisualKernel, directing it to connect to the specified host/port.
That said, due to low reliability of Qemu, this setup may trigger strange bugs, or not work at all.January 10, 2021 at 07:17 #29775
Please share it, if you have managed to setup Visual GDB debug of the Linux OS running within Qemu?
You must be logged in to reply to this topic.