On Sat, Aug 29, 2009 at 10:33:24AM +0200, Aurelien Jarno wrote: > On Sat, Aug 29, 2009 at 09:14:40AM +0200, Bastian Blank wrote: > > The system uses a amd64 kernel and userland on Xen. > This flavour works perfectly on a non-Xen system. is there also some > requirements on the compilation of glibc on Xen amd64, like on i386?
Not that I'm aware of. But the memory layout may be different. Debugging a live binary is impossible as it already breaks before the debugging setup. A core file shows: | #0 0xf7fb1000 in ?? () | #1 0xf7e0bdc8 in _init () at /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24 This seems to come from /lib/i686/cmov/libpthread.so.0 | #2 0xf7fbf284 in call_init (l=0xf7dfd720, argc=1, argv=0xffa03094, env=0xffa0309c) at dl-init.c:70 | #3 0xf7fbf416 in _dl_init (main_map=0xf7fce670, argc=1, argv=0xffa03094, env=0xffa0309c) at dl-init.c:100 | #4 0xf7fb188f in _dl_start_user () from /lib/ld-linux.so.2 | (gdb) up | #1 0xf7e0bdc8 in _init () at /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24 | 24 /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S: No such file or directory. | in /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S | Current language: auto; currently asm | (gdb) disassemble | Dump of assembler code for function _init: | 0xf7e0bdc0 <_init+0>: push %ebp | 0xf7e0bdc1 <_init+1>: mov %esp,%ebp | 0xf7e0bdc3 <_init+3>: call 0xf7e0c380 <__pthread_initialize_minimal_internal> | 0xf7e0bdc8 <_init+8>: call 0xf7e0c2c0 <frame_dummy> | 0xf7e0bdcd <_init+13>: call 0xf7e18040 <__do_global_ctors_aux> | 0xf7e0bdd2 <_init+18>: pop %ebp | 0xf7e0bdd3 <_init+19>: ret | End of assembler dump. | (gdb) disassemble 0xf7e0c2c0 | Dump of assembler code for function frame_dummy: This function seems to come from gcc. | 0xf7e0c2c0 <frame_dummy+0>: push %ebp | 0xf7e0c2c1 <frame_dummy+1>: mov %esp,%ebp | 0xf7e0c2c3 <frame_dummy+3>: push %ebx | 0xf7e0c2c4 <frame_dummy+4>: call 0xf7e0c230 <__i686.get_pc_thunk.bx> | 0xf7e0c2c9 <frame_dummy+9>: add $0x11d2b,%ebx | 0xf7e0c2cf <frame_dummy+15>: sub $0x4,%esp | 0xf7e0c2d2 <frame_dummy+18>: mov -0x214(%ebx),%edx | 0xf7e0c2d8 <frame_dummy+24>: test %edx,%edx | 0xf7e0c2da <frame_dummy+26>: je 0xf7e0c2f1 <frame_dummy+49> | 0xf7e0c2dc <frame_dummy+28>: mov -0x28(%ebx),%edx | 0xf7e0c2e2 <frame_dummy+34>: test %edx,%edx | 0xf7e0c2e4 <frame_dummy+36>: je 0xf7e0c2f1 <frame_dummy+49> | 0xf7e0c2e6 <frame_dummy+38>: lea -0x214(%ebx),%eax | 0xf7e0c2ec <frame_dummy+44>: mov %eax,(%esp) | 0xf7e0c2ef <frame_dummy+47>: call *%edx | 0xf7e0c2f1 <frame_dummy+49>: add $0x4,%esp | 0xf7e0c2f4 <frame_dummy+52>: pop %ebx | 0xf7e0c2f5 <frame_dummy+53>: pop %ebp | 0xf7e0c2f6 <frame_dummy+54>: ret | 0xf7e0c2f7 <frame_dummy+55>: nop | 0xf7e0c2f8 <frame_dummy+56>: nop | 0xf7e0c2f9 <frame_dummy+57>: nop | 0xf7e0c2fa <frame_dummy+58>: nop | 0xf7e0c2fb <frame_dummy+59>: nop | 0xf7e0c2fc <frame_dummy+60>: nop | 0xf7e0c2fd <frame_dummy+61>: nop | 0xf7e0c2fe <frame_dummy+62>: nop | 0xf7e0c2ff <frame_dummy+63>: nop | End of assembler dump. | (gdb) print {char[4]}0xf7fb1000 | $7 = "\177ELF" Hmm, just below the dynlinker, we have the vdso. If I debug a binary without using the i686/cmov libs then I miss the symbols for the vdso so, it looks like they are never used. Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org