From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IumE0-0000T2-Rq for qemu-devel@nongnu.org; Wed, 21 Nov 2007 04:50:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IumE0-0000SJ-8o for qemu-devel@nongnu.org; Wed, 21 Nov 2007 04:50:28 -0500 Received: from mx1.polytechnique.org ([129.104.30.34]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IumDz-0005uh-KO for qemu-devel@nongnu.org; Wed, 21 Nov 2007 04:50:27 -0500 Received: from fbe1.dev.netgem.com (gw.netgem.com [195.68.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id DE43A33185 for ; Wed, 21 Nov 2007 10:50:23 +0100 (CET) Message-ID: <4743FF5E.7050503@bellard.org> Date: Wed, 21 Nov 2007 10:50:22 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] SH4 Fix missing 6th arg of syscall. References: <20071121102829.6EF6.ASA@lineo.co.jp> <20071121133257.6F01.ASA@lineo.co.jp> In-Reply-To: <20071121133257.6F01.ASA@lineo.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Can you provide a glibc and busybox binary for sh4eb so that I can include them in the linux user tests ? Regards, Fabrice. Tomoyoshi ASANO wrote: > Hello, > > I tested big-endian binaries by sh4(eb)-linux-user > with a small patch(attached) for building sh4eb-linux-user. > But I don't understand that this patch is needed or not. > > sh4eb-linux-user is OK using static link binaries. > > But I feel that sh4eb-linux-users has some problem(?) > using dynamic link binaries. > > 1) If host-os has /etc/ld.so.cache, sh4eb-linux-users is NG. > > [root@triton ~] qemu-sh4eb -strace /usr/qemu-sh4eb/bin/busybox > 28575 uname(0x4007f818) = 0 > 28575 brk(0,132617,1074264468,57,1074325300,4096) = 0x00487000 > 28575 access("/etc/ld.so.preload",04) = -1 errno=2 (No such file or > directory) > 28575 open("/etc/ld.so.cache",0,01) = 3 > 28575 fstat64(3,0x4007f234) = 0 > 28575 mmap(0,66277,1,2,3,0) = 0x42081000 > 28575 close(3) = 0 > Unhandled trap: 0xa0 > pc=0x400870d0 sr=0x00008001 pr=0x40086e32 fpscr=0x00080000 > r0=0x00000348 r1=0xb61a0ff4 r2=0x2a2c1010 r3=0x0000000c > r4=0x400a4000 r5=0x40092afc r6=0x0000000b r7=0x00000002 > r8=0x7411fff4 r9=0x000102e5 r10=0x1f017fff r11=0x17dd02d5 > r12=0x400a4000 r13=0x3e02ffff r14=0x4007f2b0 r15=0x4007f2b0 > r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 > r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 > > But if no /etc/ld.so.cache in host-os, sh4eb-linux-users is OK. > > 2) If host-os has /lib/tls/*, sh4eb-linux-users is NG. > > root@triton ~] qemu-sh4eb -strace /usr/qemu-sh4eb/bin/busybox > 28580 uname(0x4007f818) = 0 > 28580 brk(0,132617,1074264468,57,1074325300,4096) = 0x00487000 > 28580 access("/etc/ld.so.preload",04) = -1 errno=2 (No such file or > directory) > 28580 open("/etc/ld.so.cache",0,01) = -1 errno=2 (No such file or > directory) > 28580 open("/lib/tls/libm.so.6",0,012) = 3 > 28580 read(3,0x4007f308,512) = 512 > 28580 close(3) = 0 > 28580 writev(2,0x4007efb8,0xa)/usr/qemu-sh4eb/bin/busybox: error > while loading shared libraries: /lib/tls/libm.so.6: ELF file data > encoding not big-endian > = 125 > 28580 exit_group(127) > > But if no /lib/tls in host-os, sh4eb-linux-users is OK. > > please help if possible. > > Thanks, > -- > > On Wed, 21 Nov 2007 10:43:49 +0900 > Tomoyoshi ASANO wrote: > >> Hell, >> >> This is very nice! >> >> I tested using glibc-2.5 >> It seems good. >> >> Thank you >> >> On Wed, 21 Nov 2007 09:24:41 +0900 >> "Magnus Damm" wrote: >> >>> Hi there, >>> >>> On Nov 20, 2007 11:48 PM, wrote: >>>> I found 6th arg for syscall is missing on SH4 linux-user emulation. >>>> This seems to be the cause of shared library mapping failure. >>>> I successfully run shared-lib'd binary, after applying following fix. >>> Hehe, I managed to create the exact same patch yesterday evening. So >>> this email is just to acknowledge this fix. Dynamically linked >>> binaries using uclibc-0.9.29 or glibc-2.3.6 both work well. Thank you. >>> >>> / magnus >>>