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

[Peter Maydell]

Added RTH to cc because IIRC you did the last lot of rearranging how
we handle these "same CPU architecture, different ABI" variants of
linux-user...

On 9 February 2015 at 14:09, Maciej W. Rozycki <address@hidden> wrote:
> 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.

I think "don't break executable names that are already present"
is a hard requirement. These get baked into binfmt-misc configurations
and effectively become part of QEMU's ABI to users.

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

So which of these four does the current "mips64/mips64el" correspond
to? That's the third in the list, right? And the current mipsn32/mipsn32el
is the fourth? So this is adding alias names for our existing targets
and creating a new one? I think I'd just leave the current names and
define new target names where we need to.

If we could figure out and write down what the design principle
is for which targets to create to handle different ABIs in linux-user
that would be handy, because at some point I need to think about
this to handle the equivalent situation for ARM (a probable
upcoming ILP32 ABI, and what to do about running 32-bit code on
64-bit CPU definitions)...

thanks
-- PMM