On Sun, May 29, 2011 at 2:32 AM, Artyom Tarasenko <atar4q...@gmail.com> wrote:
> On Thu, May 26, 2011 at 8:45 PM, Blue Swirl <blauwir...@gmail.com> wrote:
>> On Tue, May 24, 2011 at 10:42 PM, Artyom Tarasenko <atar4q...@gmail.com>
>> 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) = 0
>>> 14004 brk(NULL) = 0x00063000
>>> 14004 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or
>>> directory)
>>> 14004 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0)
>>> = 0x40a2c000
>>> 14004 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or
>>> directory)
>>> 14004 open("/etc/ld.so.cache",O_RDONLY) = 3
>>> 14004 fstat64(3,0x409ff500) = 0
>>> 14004 mmap(NULL,195479,PROT_READ,MAP_PRIVATE,3,0) = 0x40a2d000
>>> 14004 close(3) = 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$ ll ../../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$ 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=0x40a2bc00, phys_pc=<value
> optimized out>, phys_page2=1084406920) at exec.c:1214
> #5 tb_link_page (tb=0x40a2bc00, phys_pc=<value optimized out>,
> phys_page2=1084406920) at exec.c:1278
> #6 0x000000006002a037 in tb_gen_code (env=0x6223f390, pc=1084305880,
> cs_base=<value optimized out>, flags=<value optimized out>,
> cflags=<value optimized out>)
> at exec.c:1004
> #7 0x000000006002afe8 in cpu_sparc_exec (env1=<value optimized out>)
> at cpu-exec.c:636
> #8 0x0000000060005d50 in cpu_loop (env=0x6223f390) at linux-user/main.c:1008
> #9 0x00000000600069d9 in main (argc=1646342192, argv=<value optimized
> out>, envp=<value optimized out>) 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.
