Support attaching to QEMU, kgdb, and other gdbstub targets

[osandov]

The GDB Remote Serial Protocol is implemented by several debugging targets, including kgdb for the Linux kernel and QEMU. These targets are especially useful for development workflows (as opposed to debugging in production).

Basic support will require implementing alternate backends for at least the following components of drgn:

• Debug info discovery. (The protocol doesn't allow for automatic discovery, so this will likely need to be somewhat manual and depend on Module API #332).
• Memory reading.
• Threads.

The more exciting features will require new interfaces:

• Thread events (see Add thread attach/detach/event operations with ptrace #171).
• Breakpoints.
• Memory writing (see Support writing to memory #323).

[bgamari]

This would also likely unlock support for https://github.com/rr-debugger/rr, which I have found to be an invaluable tool when debugging user-space issues.

[brenns10]

One of the open questions for many of these options is going to be, how can we get the vmcoreinfo metadata for these targets. With #396, we will be able to let people manually set the vmcoreinfo prior to attaching, but it would be better if drgn could get that information automatically from the target.

Maybe a good place to get started is to add the ability to get vmcoreinfo from some of these backends where possible? EG QEMU's gdbstub could be extended to provide the cached vmcoreinfo if the guest was started with -device vmcoreinfo. I'm sure there must be some place in the GDB protocol to be able to ask for some custom piece of information...

It may be possible to get kgdb to provide a similar management command too?

[osandov]

Yeah, exactly, I was hoping that it'd be possible to add a custom GDB protocol message for this.

In the meantime, in addition to manually providing the VMCOREINFO, if KASLR is disabled and we're able to provide a vmlinux earlier in the program initialization process, we can get the vmcoreinfo note from symbols or DWARF. Terrible user experience, but probably unavoidable at the moment.