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
