[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all re
From: |
Maciej W. Rozycki |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations |
Date: |
Mon, 9 Feb 2015 14:09:54 +0000 (GMT) |
User-agent: |
Alpine 2.11 (LFD 23 2013-08-11) |
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