From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQT02-0004yw-5I for qemu-devel@nongnu.org; Sat, 28 May 2011 19:32:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QQT01-0001MI-3B for qemu-devel@nongnu.org; Sat, 28 May 2011 19:32:54 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:64660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQT01-0001MD-09 for qemu-devel@nongnu.org; Sat, 28 May 2011 19:32:53 -0400 Received: by qwj8 with SMTP id 8so1580137qwj.4 for ; Sat, 28 May 2011 16:32:52 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Sun, 29 May 2011 01:32:32 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] dynamically linked binaries under sparc-linux-user List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On Thu, May 26, 2011 at 8:45 PM, Blue Swirl wrote: > On Tue, May 24, 2011 at 10:42 PM, Artyom Tarasenko = wrote: >> Should it be possible to use dynamically linked binaries under >> sparc*-linux-user? >> Under qemu-system-sparc the Debian 4.08r1 initrd works fine, but: >> >> master$ sparc-linux-user/qemu-sparc -strace -L >> ../debian-4.08r1-initrd/ ../debian-4.08r1-initrd/bin/busybox >> 14004 uname(0x409ffbae) =3D 0 >> 14004 brk(NULL) =3D 0x00063000 >> 14004 access("/etc/ld.so.nohwcap",F_OK) =3D -1 errno=3D2 (No such file o= r directory) >> 14004 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0= ) >> =3D 0x40a2c000 >> 14004 access("/etc/ld.so.preload",R_OK) =3D -1 errno=3D2 (No such file o= r directory) >> 14004 open("/etc/ld.so.cache",O_RDONLY) =3D 3 >> 14004 fstat64(3,0x409ff500) =3D 0 >> 14004 mmap(NULL,195479,PROT_READ,MAP_PRIVATE,3,0) =3D 0x40a2d000 >> 14004 close(3) =3D 0 >> Segmentation fault >> >> The strange thing here is that it loads ld.so.cache. The guest fs >> doesn't have it, but the host does: >> >> master$ =A0ll ../../debian-4.08r1-initrd/etc/ld.so.cache /etc/ld.so.cach= e >> ls: cannot access ../../debian-4.08r1-initrd/etc/ld.so.cache: No such >> file or directory >> -rw-r--r--. 1 root root 195479 2011-03-17 13:48 /etc/ld.so.cache >> >> Isn't this wrong? > > I'm not sure. Right. On a second thought, qemu is probably doing what is expected: the syscalls are emulated, so the host libraries must be loaded. Then the problem must be elsewhere. Here is the backtrace: master$ gdb sparc-linux-user/qemu-sparc GNU gdb (GDB) Fedora (7.0.1-50.fc12) (gdb) run -L ../debian-4.08r1-initrd/ ../debian-4.08r1-initrd/bin/busybox Starting program: sparc-linux-user/qemu-sparc -L ../debian-4.08r1-initrd/ ../debian-4.08r1-initrd/bin/busybox [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00000000601c49c2 in static_code_gen_buffer () Missing separate debuginfos, use: debuginfo-install glibc-2.11.2-3.x86_64 libattr-2.4.44-1.fc12.x86_64 nspr-4.8.6-1.fc12.x86_64 nss-3.12.8-2.fc12.x86_64 nss-util-3.12.8-1.fc12.x86_64 zlib-1.2.3-23.fc12.x86_64 (gdb) bt #0 0x00000000601c49c2 in static_code_gen_buffer () #1 0x00007fffffffd684 in ?? () #2 0x00007ffff4bc8728 in ?? () #3 0x00000000ffffffff in ?? () #4 0x0000000060029083 in tb_alloc_page (tb=3D0x40a2bc00, phys_pc=3D, phys_page2=3D1084406920) at exec.c:1214 #5 tb_link_page (tb=3D0x40a2bc00, phys_pc=3D, phys_page2=3D1084406920) at exec.c:1278 #6 0x000000006002a037 in tb_gen_code (env=3D0x6223f390, pc=3D1084305880, cs_base=3D, flags=3D, cflags=3D) at exec.c:1004 #7 0x000000006002afe8 in cpu_sparc_exec (env1=3D) at cpu-exec.c:636 #8 0x0000000060005d50 in cpu_loop (env=3D0x6223f390) at linux-user/main.c:= 1008 #9 0x00000000600069d9 in main (argc=3D1646342192, argv=3D, envp=3D) at linux-user/main.c:3533 (gdb) Any ideas? > It could be possible to construct a blacklist of host > files that may not be accessible or visible to the guest but that > wouldn't very robust either. Chrooting into a 100% guest architecture > system should work better. You mean some sort of mixed chrooting? At least some host libraries must be visible to the guest as if they were native. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/