Hi Matias, Good to hear from you.
Are you saying that Toro has already implemented a gdb stub and we can "steal" it (:-) or are you suggesting we work together to implement one? I am all for that. Can you point to any documentation on how such a stub can be implemented? Also, does gdb require communication over tcp and then the guest must have the networking working? That would prevent early boot debugging. Regards, Waldek On Saturday, February 13, 2021 at 9:30:46 AM UTC-5 [email protected] wrote: > 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/37acb542-8397-4e0f-8dad-9c7ee9003596n%40googlegroups.com.
