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

[Maciej W. Rozycki]

On Wed, 10 Dec 2014, Peter Maydell wrote:

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

 Except that apart from coming to an agreement someone has to make it 
happen yet. ;)

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

 We still need to come up with sensible target names and clean up the 
current situation.  What I think is particularly important about this 
series is 3/3.  And 2/3 defines a consistent set of macros to drive 3/3.

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

 Fair enough, I want to move forward though.  Would it make you happy if I 
dropped the new -softmmu configs and made mipsn32|mipsn32el and 
mipsn64|mipsn64el only accept -user configs instead (failing gracefully 
rather than abruptly as mipsn32|mipsn32el do now)?

  Maciej