After some reading, instead of learning something I have more questions (so all the existing questions still is unknown to me): On Fri, Feb 15, 2008 at 12:12 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > > When I compiled my kernel today I noticed: > > INSTALL vdso32-int80.so > INSTALL vdso32-sysenter.so > > It seemed like a userspace dynamic library. What are these *.so files > doing in the /lib/modules/vdso directory? What are their purpose? > > vDSO - short name for ???. I have been reading everywhere but cannot > understand this. > > It is architecture specific - why only powerpc and x86 implemented this > feature, how about other arch? > > vDSO is enabled or disabled via initialization parameter, vdso=, so what > happened if it is enabled or disabled? > > I read this article: > > http://lwn.net/Articles/190139/ > > and don't quite understand the relationship between ld.so and vDSO? > > THank you for the education..... I go to /proc and "cat 4073/maps" (4073 is pid of one the userspace process - "sleep 1000 &" for example): 004ee000-00509000 r-xp 00000000 03:02 4417239 /lib/ld-2.6.so 00509000-0050a000 r--p 0001a000 03:02 4417239 /lib/ld-2.6.so 0050a000-0050b000 rw-p 0001b000 03:02 4417239 /lib/ld-2.6.so Notice that the loader (ld.so) above is loaded THREE times into the different range of virtual mem - with different read/write/exe attributes assigned to it. But the size is the same. Why such inefficiency? The process map for windows don't have such features. And same below as well? (if the space an be freed up, saving of memory is considerable) 08048000-0804c000 r-xp 00000000 03:02 2910727 /bin/sleep 0804c000-0804e000 rw-p 00003000 03:02 2910727 /bin/sleep 0804e000-0806f000 rw-p 0804e000 00:00 0 [heap] 4881d000-4896b000 r-xp 00000000 03:02 7040012 /lib/libc-2.6.so 4896b000-4896d000 r--p 0014e000 03:02 7040012 /lib/libc-2.6.so 4896d000-4896e000 rw-p 00150000 03:02 7040012 /lib/libc-2.6.so Then what is this below? And then why sometimes it is loaded only TWICE, instead of THRICE? (for example /bin/sleep above, but sometimes dynamic libraries xxx.so can be as well). 4896e000-48971000 rw-p 4896e000 00:00 0 b7d93000-b7f93000 r--p 00000000 03:02 3240856 /usr/lib/locale/locale-archive b7f93000-b7f95000 rw-p b7f93000 00:00 0 And then finally this vdso - what is that? b7fa8000-b7fa9000 r-xp b7fa8000 00:00 0 [vdso] bf893000-bf8a8000 rw-p bffeb000 00:00 0 [stack] I used gdb - for vdso cannot access, but stack can: (gdb) display /x *0xb7fa8000 4: /x *3086647296Disabling display 4 to avoid infinite recursion. = Cannot access memory at address 0xb7fa8000 (gdb) display /x *0xbf893000 5: /x *3213438976 = 0x0 Why? -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
