Re: [Qemu-devel] [PATCH 1/3] target-mips: Add n32/n64 configuration files

[Maciej W. Rozycki]

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