Add APIs for generating XML on-the-fly

[daniel5151]

As gdbstub lights up more and more of the GDB protocol, it's becoming increasingly clear that many newer GDB RSP packets boil down to the equivalent of "send back a XML document with a particular schema".

In particular, the following protocol extensions rely on XML:

• MemoryMap
• LibrariesSvr4
• Target Description XML
  • *but given how "central" this XML is to the correct operation of gdbstub... it should probably have special treatment

...not too many, but this number will only grow over time.

Today, gdbstub has taken the somewhat "lazy" approach to supporting these APIs, punting all the nuance of how to format and generate these XML documents to the end user, via an APIs that operate on raw bytes (as opposed to semantic data).

e.g: Consider gdbstub::target::ext::memory_map::MemoryMap:

    fn memory_map_xml(
        &self,
        offset: u64,
        length: usize,
        buf: &mut [u8]
    ) -> TargetResult<usize, Self>;

In order to implement this API, the user must implement a emitter for the backing XML format all by themselves: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Memory-Map-Format.html

On one hand, the task of generating these XML files isn't too difficult, and there's yet to be a user that's complained about this API... but on the other hand, it seems unfortunate that gdbstub goes through so much work to hide the details of the backing GDB RSP protocol just to "fumble at the finish line", and leak the details of how certain packets use XML to report info.

So, what to do?

Naively, it would be tempting to add APIs where the user gets a callback to report data, which gdbstub then "magically" generates XML for.

The issue with this approach is that pesky offset argument, which implies that the GDB client assumes that targets maintain an on-disk / in-memory representation of these XML files that can be queried from an arbitrary offset!

This fact, coupled with the fact that gdbstub needs to support #![no_std] implementations, implies one of two things:

• gdbstub needs to be very clever with how it generates XML on behalf of users (possibly asking the user for all data on each request, regardless of offset, and then doing math internally to regenerate and "skip" bits of XML that don't fall within the specified offset + length). maybe doable, but sounds hard. See Add support for memory maps #54 (comment) for more on this approach
  • This is just one thought though - maybe with some more thinking, a more flexible and simple solution might make itself known
• gdbstub keeps the current "raw" XML APIs, but offers helper XML Builder types that let the user decide what strategy to use when generating XML on the fly (i.e: whether to use a persistent allocation vs. re-doing work each time, etc...). See Add support for qXfer:libraries{,-svr4}:read #142 (comment) for more on this approach

I'm happy to explore both options, though my gut says that investing in XML Builders seems easier.