From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJkuX-0004Bl-Ae for qemu-devel@nongnu.org; Sun, 24 Mar 2013 09:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJkuV-00071a-TH for qemu-devel@nongnu.org; Sun, 24 Mar 2013 09:24:33 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:33070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJkuV-00071L-K9 for qemu-devel@nongnu.org; Sun, 24 Mar 2013 09:24:31 -0400 Message-ID: <514EFE8B.2040401@msgid.tls.msk.ru> Date: Sun, 24 Mar 2013 17:24:27 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <514ED8E7.7090600@msgid.tls.msk.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-x86_64 on i386 host: SIGSEGV List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: sur5r@sur5r.net, qemu-devel , Richard Henderson 24.03.2013 14:59, Peter Maydell wrote: > On 24 March 2013 10:43, Michael Tokarev wrote: >> $ ./x86_64-linux-user/qemu-x86_64 bash64 >> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >> Segmentation Fault > > Are 64 bit linux-user guests on 32 bit hosts supposed to work? > I would expect them to be at best pretty unreliable. What's the reason we build these binaries in that case? What about qemu-x86_64 on other 32bit arches (arm)? Is there a list of combinations (host/target) which are supposed to work and which don't, somewhere? >> $ gdb x86_64-linux-user/qemu-x86_64 >> (gdb) ru bash64 >> Program received signal SIGSEGV, Segmentation fault. >> disas_insn (s=s@entry=0xffffcf98, pc_start=18446744073699066880) >> at target-i386/translate.c:4107 >> 4107 b = ldub_code(s->pc); >> (gdb) p *s >> $1 = {override = -1, prefix = 1484501952, aflag = 1, dflag = 1484503884, >> pc = 18446744073699066880, is_jmp = 0, cs_base = 0, pe = 1, code32 = 1, > > PC is FFFFFFFFFF600400 so either we've messed it up already or this > is just "64 bit address space doesn't fit in a 32 bit one". >> Some binaries works - for example, gzip (it prints "qemu: Unsupported syscall: >> 202" on the way which is a different issue). > > Yes. That is just the usual "x86 linux-user isn't really supported": > 202 is TARGET_NR_futex, which works on other target archs but > won't on x86 until somebody actually fixes support for threaded > guests in x86 to at least the level it is for other targets. Maybe we should stop building x86 linux-user completely? Thanks, /mjt