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
