From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiQSp-0002k8-L7 for qemu-devel@nongnu.org; Thu, 08 May 2014 11:42:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WiQSi-0004vX-9O for qemu-devel@nongnu.org; Thu, 08 May 2014 11:42:27 -0400 Received: from mail-lb0-f171.google.com ([209.85.217.171]:35406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiQSi-0004uJ-2D for qemu-devel@nongnu.org; Thu, 08 May 2014 11:42:20 -0400 Received: by mail-lb0-f171.google.com with SMTP id 10so3807099lbg.2 for ; Thu, 08 May 2014 08:42:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1399537603-6905-1-git-send-email-dougkwan@google.com> <1399537603-6905-4-git-send-email-dougkwan@google.com> <536B978C.80107@gmail.com> From: Peter Maydell Date: Thu, 8 May 2014 16:41:57 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/3] configure: Add new target ppc64el-linux-user List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?RG91ZyBLd2FuICjpl5zmjK/lvrcp?= Cc: Tom Musta , Riku Voipio , "qemu-ppc@nongnu.org" , QEMU Developers , Alexander Graf On 8 May 2014 16:32, Doug Kwan (=E9=97=9C=E6=8C=AF=E5=BE=B7) wrote: > What else needs to be fixed? git grep ENDIAN linux-user is probably a good start on a list. > I suspect that the user-mode linux kernel > interface may also need some work but it worked well enough > in practice for us to build glibc and run gcc testsuite. The gcc testsuite is really not very much of a workout. I recommend getting a chroot environment working and then trying the LTP testsuite: http://wiki.qemu.org/Testing/LTP > Yes ELFv2 is a different ABI but it is not complete different > from the old one. A notable change is the > removal of function descriptor. That affect how the user mode start the > first instruction and that is addressed in this set of patches. It would > also affect signal handling but user-mode signals do not work at all on > PPC64 anyway and the parts that would be affected looks unimplemented. Yes, but we need to actually implement signal handling at some point, so we don't want to end up having to totally redo the base support of ppc64le at that point. The general approach linux-user takes is "one kernel ABI to one QEMU binary". Maybe we could change that, but would there be any benefit to it? I can't really see one. thanks -- PMM