From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKp2N-0003ej-5t for qemu-devel@nongnu.org; Mon, 09 Feb 2015 09:10:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKp2I-000839-MN for qemu-devel@nongnu.org; Mon, 09 Feb 2015 09:10:07 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:47476 helo=cvs.linux-mips.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKp2I-0007xc-DT for qemu-devel@nongnu.org; Mon, 09 Feb 2015 09:10:02 -0500 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S27013031AbbBIOJyONW8G convert rfc822-to-quoted-printable (ORCPT ); Mon, 9 Feb 2015 15:09:54 +0100 Date: Mon, 9 Feb 2015 14:09:54 +0000 (GMT) Sender: "Maciej W. Rozycki" From: "Maciej W. Rozycki" In-Reply-To: <54D89A42.2010004@imgtec.com> Message-ID: References: <54D89A42.2010004@imgtec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leon Alrae Cc: qemu-devel@nongnu.org, Aurelien Jarno On Mon, 9 Feb 2015, Leon Alrae wrote: > > Rework the MIPS ABIs and CPU emulations available according to the=20 > > following target list: > >=20 > > - mips|mipsel -- 32-bit CPUs only, system and user emulation = mode,=20 > > o32 user ABI, > >=20 > > - mips64|mips64el -- 32-bit and 64-bit CPUs, system and user emul= ation=20 > > mode, o32 user ABI, >=20 > 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=A2d be better off leaving it consistent across= QEMU > versions. Well, this is an example how the names could have been consistent from= =20 the beginning, and I actually agree we need to take a notion of what's=20 already there. So alternatively these could be called `mips64o32' and=20 `mips64o32el' though I find these names somewhat ugly. Although perhap= s=20 not anymore if we kept what we have now for backwards compatibility and= =20 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 bee= n > 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 chan= ge > 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-b= it=20 counterparts. Think of an o32 program run on an R10000 processor, or, = to=20 pick a more modern example, a Loongson-2E CPU. I think NetLogic or Cav= ium=20 implementations qualify here as well. I don't think hacking QEMU sourc= es=20 to add even more artificial silicon is a good way to address these case= s. Maciej