Hello everyone,

I would like to step into this topic, maybe my experience may help and also
you may help me too. A couple of months ago, I figured that I can't debug
Toro KVM guests by using the QEMU built-in gdbstub. I tried hwbreak but
that did not work either. The execution was not stopping on the
breakpoints. The QEMU built-in gdbstub works perfectly fine when KVM is not
used. I think this is a limitation of the QEMU gdbstub for x86. With a bit
of debugging, I figured out that there were actually " KVM_EXIT_DEBUG" when
breakpoints were reached but control did not go back to the gdbstub (see
QEMU tracepoints). I investigated nothing further. I wanted to avoid
writing a gdbstub for Toro but I did not have another choice. At the same
time, this allows debugging the unikernel no matters the hypervisor.

Regards, Matias.

On Wed, 3 Feb 2021 at 00:18, Waldek Kozaczuk <[email protected]> wrote:

> Currently, it is only possible to connect from gdb to a running instance
> of OSv on QEMU. But ideally, it would be nice to have a gdb stub in OSv
> that would let one connect from gdb to OSv running on any hypervisor.
>
> Per this fragment of this Wiki -
> https://github.com/cloudius-systems/osv/wiki/Debugging-OSv
>
> *"The fact that our gdb support works with the unit of cpus, not OSV
> threads, makes it convenient to debug OSV itself, but less convenient to
> debug application code running inside OSV. Particularly problematic is
> single stepping support which isn’t currently supported well: The problem
> is that when you try to look at a single OSV thread (see the next section),
> a single-step operation (“s” or “n”) makes one step inside the vcpu, not
> the osv thread*, and this step might include switching to a different
> thread. One way to work around this problem is to compile OSV with
> preemption disabled (not recommended, but can be a convenient trick in some
> debugging situations). *A better approach would have been to include a
> gdb stub into OSV itself, to allow gdb to see OSV threads directly and
> single-step them. We’ve made some progress in implementing such a stub, but
> it isn’t ready for prime-time yet.*"
>
> it looks like somebody may have implemented an initial version of the gdb
> stub. Is there a working patch of it somewhere?
>
> Regards,
> Waldek
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/a3ca8d68-5994-4b51-94c4-539e2024f12dn%40googlegroups.com
> <https://groups.google.com/d/msgid/osv-dev/a3ca8d68-5994-4b51-94c4-539e2024f12dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CA%2BdKekDtPQ%2BOfZZdiEt67wF%3DBx%3DD_C3gPJ3qYt%2Bqy06e1tC2Sw%40mail.gmail.com.

Reply via email to