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

[Peter Maydell]

On 10 December 2014 at 20:29, Maciej W. Rozycki <address@hidden> wrote:
> 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 this is only an issue because of the bare-metal ELF loading?
We should make that handle the various bare metal EXEs correctly
for the CPUs that each softmmu config currently supports.

>  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).

I think this is the right way to go.

>  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.

User emulation is a harder problem, because we compile-time code in
things like structure layouts and data type sizes. That's why we have
one binary per ABI. System emulation really should not care about
this anywhere near as much.

> 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.

The problem is that adding new QEMU executables is effectively
extending our user-facing interface. We really shouldn't do that
in the wrong way if we can avoid it (it's hard to undo later
without breaking peoples' setups).

thanks
-- PMM