Cloud Hypervisor + GDB + Arm64 Part 2: Using `gdbstub`

In this article I will introduce how “GDB remote debugging” is implemented in Cloud Hypervisor.

Generally the implementation includes 2 equally important parts:

• External gdbstub crate
• Supporting part for various debugging functionalities of Cloud Hypervisor

I created a diagram to depict the relationship between all the components involved. The components in green are from gdbstub crate. Those in blue are from Cloud Hypervisor.

Surely this is for X86_64 architecture only now.

Now let’s see how things works together.

gdbstub

gdbstub is a crate that a Rust program can integrate to support remote GDB debugging. It implements GDB Remote Serial Protocol. You can obtain gdbstub source code here.

The components of gdbstub crate:

• Target: This is the core of gdbstub. “The Target trait describes how to control and modify a system’s execution state during a GDB debugging session, and serves as the primary bridge between gdbstub’s generic protocol implementation and a target’s project/platform-specific code.”
• MultiThreadBase: The trait provides base required debugging operations for multi threaded targets.
• MultiThreadResume: Extends Target. The trait provides the support for resuming multi threaded targets.
• MultiThreadSingleStep: Extends Target. The trait provides optimized single stepping for multi threaded targets.
• Breakpoints: Extends Target. The trait defines the function of setting and removing breakpoints.
• HwBreakpoint: Extends Targetand Breakpoints. The trait defines the function of setting and removing hardware breakpoints.
• BlockingEventLoop: Provides the callbacks for event loop.

Cloud Hypervisor Components

Before talking about every components involved in Cloud Hypervisor, I need to extend the generic structure diagram that to introduce how the components interact with each other.

The stub part of the VMM acts as a proxy for other components of the VMM to talk to the GDB client. The stub runs in a separate event loop and listens to the communication channel towards the GDB client. The stub opens another channel to other VMM components (here it is Vm struct). Whenever GdbStub gets a request from GDB client, it sends a matching request to Vm. Vm handles the debugging request and responds to GdbStub, then another response will be sent back to GDB client from GdbStub.

The relevant components of Cloud Hypervisor:

• GdbStub: The most important struct for GDB support. It implements Target, MultiThreadBase, MultiThreadResume, MultiThreadSingleStep, Breakpoints and HwBreakpoint. GdbStub acts as a proxy to the VMM components for handling the protocol. It terminates the communication with GDB client for the VMM.
• GdbEventLoop: Implements BlockingEventLoop. It takes care of the events from GDB client.
• Debuggable: This trait is the abstraction of GDB functionality provided by the VMM. It is the counterpart of GdbStub. It defines the functions that the VMM software supports for debugging. These functions match those defined in gdbstub crate. The peer side components of GdbStub need to implement Debuggable trait.
• Vm: Implements Debuggable for the debugging functionality of a guest VM
• CpuManager: Implements Debuggable for the debugging functionality of VCPUs of a guest VM