Comment 2 for bug 1686170

Apparently none of the 32bit x86 modes are supported in 2.9 version of qemu-system-x86_64. I realize the desire to simplify the code, and separate i386 from x86_64, but x86_64 really does need to support all the modes in which the processor can operate. True that for major operating systems the processor is only briefly in any 32bit mode, but for boot ROM and boot loader work, and non-mainstream kernels we still very much need 32bit support *in* the x86_64 qemu.

Previously the 'g' RDP query (gdbstub.c:1056) would send a different length of reg data depending on in which mode the cpu was currently operating. Although maybe not a great ABI, it was sufficient to tell exactly when the cpu changed states and front end debuggers need to know this.

Unfortunately the much more portable new .xml register definition scheme needs to be changed to properly support multiple register sets (with different names sizes etc.), but x86 is not the only processor to have multiple personalities.
 An example implementation for x86 could be that the "top" level xml file i386-64bit.xml describes all the different possible modes (something like):

<feature name="org.gnu.gdb.i386.64bit">
  <xi:include href="i386-64bit-core.xml"/>
  <xi:include href="i386-64bit-sse.xml"/>
</feature>
<feature name="org.gnu.gdb.i386.32bit.protectedmode">
  <xi:include href="i386-32bit-core.xml"/>
  <xi:include href="i386-32bit-sse.xml"/>
</feature>
<feature name="org.gnu.gdb.i386.32bit.realmode">
  <xi:include href="i386-i8086-core.xml"/>
</feature>

all of which are loaded when the frontend starts. The 'g' RDP response should then start with one of the feature names (or an abbreviated unique id).

In fact, ring0 vs ring1-3 should likely also have different xml files as the crX config registers need to be sent when in ring 0 as well.

Commit that made this change:

https://github.com/qemu/qemu/commit/00fcd100c3f47445f6a59d39e11601460880cfe4#diff-b8f1948d6e81e8ccdbe828ba7973c483