Aside from specifying the core architecture of the target, the Target Description XML is also used to specify various features of the architecture. As the docs say: "Features are currently used to describe available CPU registers and the types of their contents"

e.g: for x86, the core registers are defined under the org.gnu.gdb.i386.core feature, while the optional SSE registers are defined under the org.gnu.gdb.i386.sse feature.

Currently, the Arch trait isn't very well suited to describing features, requiring a separate implementation for each set of features. i.e: if an architecture has 3 different features, A, B, and C, each with their own registers, there would have to be 3! (i.e: 6) different register structs to describe each set of features!

I'd like to preserve the current "described at compile time" approach to the Arch trait, and I think with a little bit of experimentation, it shouldn't be too hard to find some sort of ergonomic trait-based solution to the problem.

Some general ideas:

• It might make sense to have the target_features_xml method accept a FnMut(&'static str) callback (instead of returning Option<'static str>, as that would allow building up an XML file in "chunks" based on which features are available.