Rob Landley schrieb: > Ok, it's a more fundamental problem: > > [EMAIL PROTECTED]:/sys$ qemu-i386 > Segmentation fault (core dumped) > > Nothing to do with the program it's trying to run, it segfaults with no > arguments. > > Is anybody else seeing this? > > Rob Yes, I see this on Debian Linux since several months (libc update?).
The crash is caused by libc startup code which calls a null pointer. QEMU provides this null pointer with the __init_array_start workaround in linux-user/main.c. This can be fixed with some kind of code hack - see my patch (which is not really a solution, but one more workaround). Nevertheless user mode emulations remains unusable even with this patch because of TLS problems. Regards, Stefan
Index: linux-user/main.c =================================================================== RCS file: /sources/qemu/qemu/linux-user/main.c,v retrieving revision 1.116 diff -u -b -B -r1.116 main.c --- linux-user/main.c 21 Jun 2007 22:55:02 -0000 1.116 +++ linux-user/main.c 23 Jun 2007 11:03:42 -0000 @@ -45,12 +45,16 @@ /* for recent libc, we add these dummy symbols which are not declared when generating a linked object (bug in ld ?) */ #if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && !defined(CONFIG_STATIC) -long __preinit_array_start[0]; -long __preinit_array_end[0]; -long __init_array_start[0]; -long __init_array_end[0]; -long __fini_array_start[0]; -long __fini_array_end[0]; +typedef void (*dummy_function_t)(void); +static void dummy_function(void) +{ +} +dummy_function_t __preinit_array_start = dummy_function; +dummy_function_t __preinit_array_end = dummy_function; +dummy_function_t __init_array_start = dummy_function; +dummy_function_t __init_array_end = dummy_function; +dummy_function_t __fini_array_start = dummy_function; +dummy_function_t __fini_array_end = dummy_function; #endif /* XXX: on x86 MAP_GROWSDOWN only works if ESP <= address + 32, so