[Qemu-devel] [PATCH 0/3] MIPS: GDB register width fix / ABI configuration rework

[Maciej W. Rozycki]

Hi,

 This mini patch series corrects some misguided assumptions in QEMU's MIPS 
processor selection while also adding another configuration to support a 
missing ABI-processor combination, and then corrects register widths used 
by the GDB stub so as to match the processor selected (for the system 
emulation mode) or the ABI selected (for the user emulation mode), to 
match GDB's expectations.

 Ideally we should be using XML register descriptions to communicate 
hardware (raw) register widths, but GDB is not yet prepared for it, not 
for the system emulation mode, that is.  This rework does not preclude 
such an improvement in the future once GDB is capable enough, which would 
apply directly on top as the registers widths set here are the correct 
ones for each of the configurations concerned.  Without XML support the 
correct processor type has to be selected in GDB manually such as to 
match one selected in QEMU for emulation; this does note have to be an 
exact match, it only has to be close enough.

 Also ideally we'd support two configurations only, mips|mipsel and 
mips64|mips64el, and be able to load any compatible ELF executable, 
either 32-bit i.e. ELF32 non-ABI2 (with both configurations) or 64-bit 
i.e. ELF64 or ELF32 ABI2 (with the latter configuration only), into the 
same binary, in the user emulation mode case also selecting the correct 
ABI and consequently syscall environment on the fly, one of o32 (again 
with both configurations), n32 (with the latter configuration only) and 
n64 (likewise).  Again, this can be done in the future as resources 
permit as this appears to me it would be a major effort.

 The current arrangement for the existing QEMU configurations is as 
follows:

1. mips|mipsel       -- 32-bit processors only, o32 user-mode and GDB ABI,

2. mipsn32|mipsn32el -- 32-bit and 64-bit processors, n32 user-mode and 
                        n64 GDB ABI,

3. mips64|mips64el   -- 32-bit and 64-bit processors, n64 user-mode and 
                        GDB ABI.

 I have made no changes to the first configuration, except from providing 
an extra TARGET_MIPS32 macro to make a separate selection of 32-bit 
processors possible.

 Configurations #2 and #3 suffer from the fundamental problem that both 
the n32 and the n64 ABI require a 64-bit processor.  These configurations 
are therefore buggy -- no 32-bit processor should be available for them.  
Additionally we're missing an o32 ABI configuration that would permit 
64-bit processors, as that ABI is in fact compatible with such processors.  
Finally for mipsn32|mipsn32el the GDB RSP stub's ABI does not match the 
name of the configuration and also the user-mode ABI.

 I have therefore made changes to arrange for the following 
configurations:

1. mips|mipsel       -- 32-bit processors only, o32 user-mode and GDB ABI,

2. mips64|mips64el   -- 32-bit and 64-bit processors, o32 user-mode and 
                        GDB ABI,

3. mipsn32|mipsn32el -- 64-bit processors only, n32 user-mode and GDB ABI,

4. mipsn64|mipsn64el -- 64-bit processors only, n64 user-mode and GDB ABI.

I consider the choice of target names, and in particular the change of the 
semantics of "mips64|mips64el", a starting point for discussion.  I think 
the choice I made is about the most natural, an alternative might be 
embedding the name of the ABI into all targets, e.g.:

1. mipso32|mipso32el,

2. mips64o32|mips64o32el,

3. mips64n32|mips64n32el,

4. mips64n64|mips64n64el.

 We might consider discarding configuration #1 altogether as redundant, 
but my understanding is we have it mainly for performance reasons as it 
makes all internal target data types at most 32-bit wide, that has a 
code/data size benefit and also, on 32-bit hosts, processing time benefit.

 Configuration #2 is OTOH important to be able to use 32-bit features, 
regularly available to o32 programs, of these 64-bit processors that have 
no 32-bit counterparts.  In particular legacy MIPS architecture 
implementations and their properties such as the CP1.FCSR.FS bit of the 
R4000 processor for 32-bit MIPS III software, or the MIPS IV instruction 
subset of the VR5432 processor for 32-bit MIPS IV software.  It may be of 
a little bit less importance for contemporary MIPS architecture 
implementations that have more symmetry with the existence of the MIPS32 
and MIPS64 flavours in parallel, but I think this still makes sense for 
consistency if nothing else.

 Additionally I made clean-ups throughout, including but not limited to 
tying up some ABI-dependent properties to the respective ABI macros rather 
than the 64-bit configuration macro.

 These changes were validated as a side effect of the IEEE 754-2008 
updates posted recently, that were regression-tested with this patch set 
already applied.

 Comments?

  Maciej