[x86] Expose segment base MSRs about gdbstub

[daniel5151]

If you take a peek at the current x86 arch defn, you'll find that it reports the following target.xml

<target version="1.0">
    <architecture>i386:x86-64</architecture>
    <feature name="org.gnu.gdb.i386.sse"></feature>
</target>

You can use the in-tree Arch implementation as a starting off point for a custom out-of-tree implementation that reports this additional feature:

<target version="1.0">
    <architecture>i386:x86-64</architecture>
    <feature name="org.gnu.gdb.i386.sse"></feature>
    <feature name="org.gnu.gdb.i386.segments"></feature>
</target>

You'll need to define a custom Registers implementation that includes these additional registers as well:

struct X86_64_SegmentsRegs {
    fs_base: u64,
    gs_base: u64,
}

// and then package it up alongside the existing register defn
struct X86_64_SSE_SegmentsRegs {
    core: gdbstub_arch::x86::reg::X86_64CoreRegs,
    segments: X86_64_SegmentsRegs
}

These are all public traits, and can be implemented by types outside of the main gdbstub repo. This makes it easy to get an implementation up-and-running without having to use a custom local version of gdbstub. Once you get something working that you're happy with, feel free to open a PR to upstream it.

---

Now, while the above solution is all well and good, it does touch upon a larger and long-standing issue in gdbstub that I never found a good time to sort out: what's a good way to support fine-grained control over available target features / registers without requiring a combinatorial explosion of Arch implementations? More details of what I mean in #12.

I bring this up not as a call-to-action, but moreso as a reminder to my future self that I really need to stop kicking this issue down the road, and actually fixing this. After all, at the time of writing, there are 8 different x86 feature sets that can all be (theoretically) mixed and matched: https://sourceware.org/gdb/onlinedocs/gdb/i386-Features.html#i386-Features. Handling all combinations of features would require 8! == 40320 impls, which isn't at all sustainable!