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
