That's useful information, and I thought I'd also share a slightly different workaround for this issue that I use in Solo5 (which I expect can be done similarly with Rumprun).
For Solo5, the way I get around this issue is to set a volatile variable at the start of main and loop on it infinitely, then change the value of the variable via gdb once gdb is attached. It's not able to connect gdb without editing any source like your way does, but it only requires running gdb once. Here are my steps:
1. Edit kernel.c to set the volatile "gdb" variable to 0 (https://github.com/djwillia/solo5/blob/mirage/kernel/kernel.c#L28)
2. Start the unikernel with the QEMU gdb stub enabled (-s). It will get stuck in an infinite loop and print "looping for gdb" (https://github.com/djwillia/solo5/blob/mirage/kernel/kernel.c#L36)
3. Start gdb using the 64-bit kernel ELF binary:
gdb kernel/kernel
4. Connect gdb to the QEMU stub
target remote localhost:1234
5. Cause the infinite loop to break by changing the value of the "gdb" variable to 1
set gdb=1
6. Continue execution via gdb
c
Steps 3,4, and 5 can be done with one line thanks to https://github.com/djwillia/solo5/blob/mirage/gdb.txt
gdb kernel/kernel --command gdb.txt
Thanks,
Dan
Dan
----- Original message -----
From: Martin Lucina <[email protected]>
Sent by: "MirageOS-devel" <[email protected]>
To: [email protected]
Cc:
Subject: [MirageOS-devel] (Fwd) Workaround for debugging 64-bit unikernels under KVM/QEMU
Date: Tue, Mar 15, 2016 12:49 PM
Hi folks,
forwarding this, useful for anyone debugging either Mirage/Rumprun or
Mirage/Solo5 under KVM/QEMU. For Solo5, you'll want to replace 'x86_boot'
symbol with the equivalent 64-bit startup function.
Cheers
Martin
----- Forwarded message from Martin Lucina <[email protected]> -----
Date: Tue, 15 Mar 2016 17:30:37 +0100
From: Martin Lucina <[email protected]>
To: [email protected]
Subject: Workaround for debugging 64-bit unikernels under KVM/QEMU
Hi all,
I've managed to find a workaround for the well-known problem of GDB not
being able to debug hw/x86-64 unikernels under QEMU or KVM (see GDB issue
https://sourceware.org/bugzilla/show_bug.cgi?id=13984):
1. Start the unikernel, leaving it paused and waiting for GDB to connect:
rumprun [kvm|qemu] -p -D 1234 [...]
2. Run the following GDB command:
gdb -q -ex "target remote:1234" -ex "hbreak x86_boot" -ex "continue" -ex "disconnect" -ex "quit" unikernel.bin
This will cause the unikernel to proceed past the transition from 32-bit
mode to long mode and remain in a paused state.
3. Re-launch GDB a second time as you would normally.
I've updated the "Howto: Debugging Rumprun with GDB" page on the wiki with
these instructions.
The workaround works for both QEMU and KVM. The trick seems to be to a;ways
use a hardware-assisted breakpoint on x86_boot. 'disconnect' ensures
QEMU/KVM remains paused and 'quit' followed by a restart is needed to
de-confuse GDB.
Martin
----- End forwarded message -----
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
