Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

[Maciej W. Rozycki]

On Mon, 9 Feb 2015, Leon Alrae wrote:

> > Rework the MIPS ABIs and CPU emulations available according to the 
> > following target list:
> > 
> > - mips|mipsel       -- 32-bit CPUs only, system and user emulation mode, 
> >                        o32 user ABI,
> > 
> > - mips64|mips64el   -- 32-bit and 64-bit CPUs, system and user emulation 
> >                        mode, o32 user ABI,
> 
> I'm not sure if it's a good idea to change the meaning of linux-user
> qemu-mips64 and qemu-mips64el, this will cause unnecessary confusion in
> my opinion. I think we’d be better off leaving it consistent across QEMU
> versions.

 Well, this is an example how the names could have been consistent from 
the beginning, and I actually agree we need to take a notion of what's 
already there.  So alternatively these could be called `mips64o32' and 
`mips64o32el' though I find these names somewhat ugly.  Although perhaps 
not anymore if we kept what we have now for backwards compatibility and 
added a set of uniform target names like this:

- mips32o32|mips32o32el (or maybe just mipso32|mipso32el),

- mips64o32|mips64o32el,

- mips64n64|mips64n64el,

- mips64n32|mips64n32el.

Or maybe just the three latters, leaving mips|mipsel as it is.  WDYT?

> Do we really need MIPS64 executables for o32 ABI for linux-user? They
> would merely enable MIPS64 CPUs to run o32 programs. So far we've been
> handling this by using 32-bit CPUs (artificial if the real CPU don't
> exist), therefore I don't see an issue here. Also I'm concerned that
> once we add new executables, it will be difficult to revert that change
> later, thus we must be certain that this is the right way to go.

 There is a slight difference for some processors that do not have 32-bit 
counterparts.  Think of an o32 program run on an R10000 processor, or, to 
pick a more modern example, a Loongson-2E CPU.  I think NetLogic or Cavium 
implementations qualify here as well.  I don't think hacking QEMU sources 
to add even more artificial silicon is a good way to address these cases.

  Maciej