From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSmG7-0005J0-8S for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:31:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSmG5-0003bf-Tw for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:31:03 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:40893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSmG5-0003ba-P3 for qemu-devel@nongnu.org; Sat, 04 Jun 2011 04:31:01 -0400 Received: by qwj8 with SMTP id 8so1323214qwj.4 for ; Sat, 04 Jun 2011 01:31:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Sat, 4 Jun 2011 11:30:40 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Artyom Tarasenko Cc: qemu-devel On Sun, May 29, 2011 at 2:32 AM, Artyom Tarasenko wro= te: > 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 = or 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 = or 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$ =C2=A0ll ../../debian-4.08r1-initrd/etc/ld.so.cache /etc/ld.so.= cache >>> 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$ =C2=A0gdb 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 =C2=A00x00000000601c49c2 in static_code_gen_buffer () > #1 =C2=A00x00007fffffffd684 in ?? () > #2 =C2=A00x00007ffff4bc8728 in ?? () > #3 =C2=A00x00000000ffffffff in ?? () > #4 =C2=A00x0000000060029083 in tb_alloc_page (tb=3D0x40a2bc00, phys_pc=3D= optimized out>, phys_page2=3D1084406920) at exec.c:1214 > #5 =C2=A0tb_link_page (tb=3D0x40a2bc00, phys_pc=3D, > phys_page2=3D1084406920) at exec.c:1278 > #6 =C2=A00x000000006002a037 in tb_gen_code (env=3D0x6223f390, pc=3D108430= 5880, > cs_base=3D, flags=3D, > cflags=3D) > =C2=A0 =C2=A0at exec.c:1004 > #7 =C2=A00x000000006002afe8 in cpu_sparc_exec (env1=3D) > at cpu-exec.c:636 > #8 =C2=A00x0000000060005d50 in cpu_loop (env=3D0x6223f390) at linux-user/= main.c:1008 > #9 =C2=A00x00000000600069d9 in main (argc=3D1646342192, argv=3D out>, envp=3D) at linux-user/main.c:3533 > (gdb) > > Any ideas? The logs would probably show the crashing instruction. >> 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. The simplest way is to build a statically linked emulator, chroot to the guest system and execute the emulator. Then the only host executable should be QEMU itself. Maybe binfmt_misc can also be used. A more complex way would be to introduce chrooting into QEMU user emulators, then the emulator could remain dynamically linked. Though libraries loaded at run time (NSS?) could cause problems.