Hi Edgar, On Sat, Oct 17, 2009 at 9:57 PM, Edgar E. Iglesias <edgar.igles...@gmail.com> wrote: > > It feels a bit strange to have the CPU model know about linux vsyscalls. > Did you consider having the linux-user loader pass a qemu version of the > x86_64 vdso to the guest through the auxvector? That version could probably > implement the vsyscalls by translating them into syscalls with x86_64 code. > It probably doesn't even need to do that btw, just make sure to fill it > with syscall insns to raise exceptions and then have the linux-user/ code > treat syscalls with eip from vdso page differently. That way the CPU model > doesn't need to know about vdso and you can implement vsyscalls that may > need magic interactions with qemu. > > Or does that not work for some reason? Performance? > Are there maybe old binaries that don't look in the auxvector and just assume > a fixed address for the vdso?
A recent compiler (gcc 4.4.0) produces this code for a statically compiled program: 00000000005779e0 <time>: 5779e0: 48 83 ec 08 sub $0x8,%rsp 5779e4: 48 c7 c0 00 04 60 ff mov $0xffffffffff600400,%rax 5779eb: ff d0 callq *%rax 5779ed: 48 83 c4 08 add $0x8,%rsp 5779f1: c3 retq I never heard of "auxvector" before. Is this related to what is discussed here? http://manugarg.googlepages.com/aboutelfauxiliaryvectors I dumped 4KB mapped at AT_SYSINFO_EHDR and processed it through readelf. Nothing matches the address above: 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: ffffffffff70030c 0 SECTION LOCAL DEFAULT 7 2: ffffffffff700800 74 FUNC WEAK DEFAULT 12 clock_gettime@@LINUX_2.6 3: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6 4: ffffffffff7006c0 137 FUNC GLOBAL DEFAULT 12 __vdso_gettimeofday@@LINUX_2.6 5: ffffffffff700850 61 FUNC GLOBAL DEFAULT 12 __vdso_getcpu@@LINUX_2.6 6: ffffffffff7006c0 137 FUNC WEAK DEFAULT 12 gettimeofday@@LINUX_2.6 7: ffffffffff700850 61 FUNC WEAK DEFAULT 12 getcpu@@LINUX_2.6 8: ffffffffff700800 74 FUNC GLOBAL DEFAULT 12 __vdso_clock_gettime@@LINUX_2.6 I probably missed your point :-) Thanks, Laurent
