On Wed, 10 Dec 2014, Peter Maydell wrote:
> > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak
> > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak
> > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak
> > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak
>
> Some of these look weird. n32 and n64 are ABIs, right? We
> shouldn't have extra -softmmu configs for different ABIs,
> the guest can deal with those. The MIPS config name variants
> that are only ABI related should only result in new -linux-user
> binaries (where we need a binary per Linux syscall ABI).
This is a tricky change, the system emulation mode configuration also has
an ELF loader (invoked with the -kernel option) and as such is also
affected. There are three MIPS ELF flavours corresponding to the three
ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is
an ELF file header flag). The two ELF32 flavours are I think close enough
to each other as far as executables (as opposed to intermediate objects)
are concerned that a single QEMU binary might be able to handle them as it
stands. Of course ELF32 ABI2 is incompatible to any 32-bit processors and
such executables must be rejected when emulating a 32-bit processor.
So with my proposal and -softmmu configs:
- mipsn64|mipsn64el -- handle ELF64 (n64) binaries with only 64-bit
processors available for emulation,
- mipsn32|mipsn32el -- handle ELF32 (n32) binaries with only 64-bit
processors available for emulation,
- mips64|mips64el -- handle ELF32 (o32, maybe n32) binaries with both
32-bit and 64-bit processors available for
emulation,
- mips|mipsel -- handle ELF32 (o32) binaries with only 32-bit
processors available for emulation (configuration
optimised for 32-bit hosts).
Each of them will be suitable for running different bare-metal
applications. As I say, we may be able to come up with better target
names, I am open to proposals.
As noted in 0/3 ideally we'd handle all ELF flavours with a single
binary. Then we could have two system configurations only, mips|mipsel (a
limited configuration for 32-bit host optimisation) and mips64|mips64el (a
full configuration). That could apply to both the system and the user
emulation mode, although the effort required to handle the former is a
subset of that for the latter, and also looks quite substantially smaller
to me. The changes I propose here do not preclude it from happening in
the future, they are merely intended to bring some order to what we have
now.
Does this explanation makes things addressed here a bit clearer to you?
Maciej
