Xen project Mailing List

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

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

----- Original message -----
From: Martin Lucina <martin@xxxxxxxxxx>
Sent by: "MirageOS-devel" <mirageos-devel-bounces@xxxxxxxxxxxxxxxxxxxx>
To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
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 <martin@xxxxxxxxxx> -----

Date: Tue, 15 Mar 2016 17:30:37 +0100
From: Martin Lucina <martin@xxxxxxxxxx>
To: rumpkernel-users@xxxxxxxxxxxxx
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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Re: [MirageOS-devel] (Fwd) Workaround for debugging 64-bit unikernels under KVM/QEMU