Bug#544145: libc6-i686 - Segfaults on amd64/xen
On Sat, Aug 29, 2009 at 11:31:43AM +0200, Bastian Blank wrote:
> Hmm, just below the dynlinker, we have the vdso.
vdso was the point. However I don't know what the real problem is. A
minimal failing program is:
| int main() {
| unsigned int resultvar;
| asm volatile (
| "movl %1, %%eax\n\t"
| "call *%%gs:0x10\n\t"
| : "=a" (resultvar)
| : "i" (0) : "memory", "cc");
| }
This just calls the syscall 0 through the vdso and on my system this
produces the following:
| (gdb) run
| Starting program: /test
|
| Program received signal SIGSEGV, Segmentation fault.
| 0xf7fdf42f in __kernel_vsyscall ()
| (gdb) bt
| #0 0xf7fdf42f in __kernel_vsyscall ()
| #1 0xf7fd6ff4 in ?? () from /lib/libc.so.6
| #2 0xf7eb07a5 in __libc_start_main (main=0x8048394 <main>, argc=1, ubp_av=0xffffd884, init=0x80483d0 <__libc_csu_init>,
| fini=0x80483c0 <__libc_csu_fini>, rtld_fini=0xf7fee6e0 <_dl_fini>, stack_end=0xffffd87c) at libc-start.c:222
| #3 0x08048301 in _start () at ../sysdeps/i386/elf/start.S:119
| (gdb) disassemble
| Dump of assembler code for function __kernel_vsyscall:
| 0xf7fdf420 <__kernel_vsyscall+0>: push %ebp
| 0xf7fdf421 <__kernel_vsyscall+1>: mov %ecx,%ebp
| 0xf7fdf423 <__kernel_vsyscall+3>: syscall
| 0xf7fdf425 <__kernel_vsyscall+5>: mov $0x2b,%ecx
| 0xf7fdf42a <__kernel_vsyscall+10>: mov %ecx,%ss
| 0xf7fdf42c <__kernel_vsyscall+12>: mov %ebp,%ecx
| 0xf7fdf42e <__kernel_vsyscall+14>: pop %ebp
| 0xf7fdf42f <__kernel_vsyscall+15>: ret
| End of assembler dump.
> 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.
This binaries don't use the vdso in the INLINE_SYSCALL macro.
A check in the Xen source show the following changeset, which is missing
in this hypervisor:
| user: Keir Fraser <keir.fraser@citrix.com>
| date: Fri Dec 05 15:21:59 2008 +0000
| files: xen/arch/x86/x86_64/compat/entry.S
| description:
| x86/32on64: adjust address when converting syscall to fault
|
| The faulting address is at the start of the syscall instruction rather
| than at the following one.
Looks like the problem is caught. Will check this tomorrow.
Bastian
--
Sometimes a feeling is all we humans have to go on.
-- Kirk, "A Taste of Armageddon", stardate 3193.9
Reply to: