• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-19  評論-21  文章-0  trackbacks-0

                 傳統(tǒng)的系統(tǒng)調(diào)用是怎樣的?    —— int 0x80的時代

            ....             ;通過寄存器傳參
            mov $n ,eax      ;將系統(tǒng)調(diào)用號放到eax中
            int 0x80


            sysenter/sysexit的出場

                    在一個Kernel.org的郵件列表中,有一封郵件討論了“"Intel P6 vs P7 system call performance”,最后得出的結(jié)論是采用傳統(tǒng)的int 0x80的系統(tǒng)調(diào)用浪費了很多時間(具體原因可以看參考資料1),而sysenter/sysexit可以彌補這個缺點,所以決定在linux內(nèi)核中用后都替換前者(最終在2.6版本的內(nèi)核中才加入了此功能,即采用sysenter/sysexit)。

                    在替換之前首先需要知道滿足如下條件的ntel機器才會有sysenter/sysexit指令對:Family >= 6,Model >= 3,Stepping >= 3

                    如何用替換sysenter/sysexit替換以前的int 0x80呢?linux kenerl 需要考慮到這點:有的機器并不支持sysenter/sysexit  , 于是它跟glibc說好了,“你以后調(diào)用系統(tǒng)調(diào)用的時候就從我給你的這個地址調(diào)用,這個地址指向的內(nèi)容要么是int 0x80調(diào)用方式,要么是sysenter/sysexit調(diào)用方式,我會根據(jù)機器來選擇其中一個”(kernel與glibc的配合是如此的默契),這個地址便是vsyscall的首地址。

                     可以將vdso看成一個shared objdect file(這個文件實際上不存在),內(nèi)核將其映射到某個地址空間,被所有程序所共享。(我覺得這里用到了一個技術(shù):多個虛擬頁面映射到同一個物理頁面。即內(nèi)核把vdso映射到某個物理頁面上,然后所有程序都會有一個頁表項指向它,以此來共享,這樣每個程序的vdso地址就可以不相同了)

            hex108@ubuntu:~/program$ uname -a
            Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux
            hex108@ubuntu:~/program$ sudo sysctl -w kernel.randomize_va_space=0 //這個是必須的,否則vdso的地址是隨機的(vsyscall的地址也會相應(yīng)
                                                                                    // 地發(fā)生變化 ),在下面dd的時候就會出現(xiàn)錯誤
                                                                                    //dd: reading `/proc/self/mem': Input/output error
                                                                                    
            kernel.randomize_va_space = 0
            hex108@ubuntu:~/program$ cat /proc/self/maps 
            00110000-0012c000 r-xp 00000000 08:01 260639     /lib/ld-2.12.1.so
            0012c000-0012d000 r--p 0001b000 08:01 260639     /lib/ld-2.12.1.so
            0012d000-0012e000 rw-p 0001c000 08:01 260639     /lib/ld-2.12.1.so
            0012e000-0012f000 r-xp 00000000 00:00 0          [vdso]
            0012f000-00286000 r-xp 00000000 08:01 260663     /lib/libc-2.12.1.so
            00286000-00287000 ---p 00157000 08:01 260663     /lib/libc-2.12.1.so
            00287000-00289000 r--p 00157000 08:01 260663     /lib/libc-2.12.1.so
            00289000-0028a000 rw-p 00159000 08:01 260663     /lib/libc-2.12.1.so
            0028a000-0028d000 rw-p 00000000 00:00 0 
            08048000-08051000 r-xp 00000000 08:01 130326     /bin/cat
            08051000-08052000 r--p 00008000 08:01 130326     /bin/cat
            08052000-08053000 rw-p 00009000 08:01 130326     /bin/cat
            08053000-08074000 rw-p 00000000 00:00 0          [heap]
            b7df0000-b7ff0000 r--p 00000000 08:01 660864     /usr/lib/locale/locale-archive
            b7ff0000-b7ff1000 rw-p 00000000 00:00 0 
            b7ffd000-b7ffe000 r--p 002a1000 08:01 660864     /usr/lib/locale/locale-archive
            b7ffe000-b8000000 rw-p 00000000 00:00 0 
            bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]
            hex108@ubuntu:~/program$ dd if=/proc/self/mem of=gate.so bs=4096 skip=$[0x12e] count=1
            dd: `/proc/self/mem': cannot skip to specified offset
            1+0 records in
            1+0 records out
            4096 bytes (4.1 kB) copied, 0.00176447 s, 2.3 MB/s
            hex108@ubuntu:~/program$ file gate.so 
            gate.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
            hex108@ubuntu:~/program$ objdump -d gate.so 
            
            gate.so:     file format elf32-i386
            
            
            Disassembly of section .text:
            
            ffffe400 <__kernel_sigreturn>:
            ffffe400:	58                   	pop    %eax
            ffffe401:	b8 77 00 00 00       	mov    $0x77,%eax
            ffffe406:	cd 80                	int    $0x80
            ffffe408:	90                   	nop
            ffffe409:	8d 76 00             	lea    0x0(%esi),%esi
            
            ffffe40c <__kernel_rt_sigreturn>:
            ffffe40c:	b8 ad 00 00 00       	mov    $0xad,%eax
            ffffe411:	cd 80                	int    $0x80
            ffffe413:	90                   	nop
            
            ffffe414 <__kernel_vsyscall>:
            ffffe414:	cd 80                	int    $0x80
            ffffe416:	c3                   	ret    
             

            syscall 才是最后的贏家?

                     x86 64位從AMD引進了syscall指令(我在x86 64的機器上,看到的結(jié)果是syscall取代了sysenter/sysexit(所有的系統(tǒng)調(diào)用用的都是syscall)),但是vdso,vsyscall的機制依舊未變,只是kernel決定只在遇到以下幾個系統(tǒng)調(diào)用gettimeofday,time和getcpu(通過內(nèi)核里vsyscall.h中enum vsyscall_num的聲明看出來,或者在glibc源代碼中搜索“VSYSCALL_ADDR_”(

            #define VSYSCALL_ADDR_vgettimeofday    0xffffffffff600000

            #define VSYSCALL_ADDR_vtime            0xffffffffff600400

            #define VSYSCALL_ADDR_vgetcpu          0xffffffffff600800

            ))時才采用vdso機制(間接調(diào)用syscall,具體可以參看資料2),其他系統(tǒng)調(diào)用直接用指令syscall,原因是:


             

                     "快速系統(tǒng)調(diào)用指令"比起中斷指令來說,其消耗時間必然會少一些,但是隨著 CPU 設(shè)計的發(fā)展,將來應(yīng)該不會再出現(xiàn)類似 Intel Pentium4 這樣懸殊的差距。而"快速系統(tǒng)調(diào)用指令"比起中斷方式的系統(tǒng)調(diào)用方式,還存在一定局限,例如無法在一個系統(tǒng)調(diào)用處理過程中再通過"快速系統(tǒng)調(diào)用指令"調(diào)用別的系統(tǒng)調(diào)用。因此,并不一定每個系統(tǒng)調(diào)用都需要通過"快速系統(tǒng)調(diào)用指令"來實現(xiàn)。比如,對于復(fù)雜的系統(tǒng)調(diào)用例如 fork,兩種系統(tǒng)調(diào)用方式的時間差和系統(tǒng)調(diào)用本身運行消耗的時間來比,可以忽略不計,此處采取"快速系統(tǒng)調(diào)用指令"方式?jīng)]有什么必要。而真正應(yīng)該使用"快速系統(tǒng)調(diào)用指令"方式的,是那些本身運行時間很短,對時間精確性要求高的系統(tǒng)調(diào)用,例如 getuid、gettimeofday 等等。因此,采取靈活的手段,針對不同的系統(tǒng)調(diào)用采取不同的方式,才能得到最優(yōu)化的性能和實現(xiàn)最完美的功能。      ----引自參考資料1



                  

             

            ps:文中的內(nèi)核版本為2.6.36,glibc版本為2.11

            參考資料:

            1.  Linux 2.6 對新型 CPU 快速系統(tǒng)調(diào)用的支持: http://www.ibm.com/developerworks/cn/linux/kernel/l-k26ncpu/index.html  (這篇我覺得最好)

            2. System Callshttp://www.win.tue.nl/~aeb/linux/lk/lk-4.html(里面有程序可以用來搜索vsyscall等的地址,很直接)

            3. What is linux-gate.so.1http://www.trilithium.com/johan/2005/08/linux-gate/

            4. Intel手冊,里面有各種資料,手冊還是很重要的,也是最基本的

            posted on 2010-11-22 21:19 hex108 閱讀(12392) 評論(0)  編輯 收藏 引用 所屬分類: Kernel
            中文字幕精品无码久久久久久3D日动漫| 丁香色欲久久久久久综合网| 精品一区二区久久久久久久网站| 97久久超碰国产精品2021| 久久久久中文字幕| 亚洲另类欧美综合久久图片区| 狠狠综合久久综合88亚洲| 国产精品久久久久aaaa| 亚洲欧美日韩久久精品| 麻豆AV一区二区三区久久| 国内精品久久久久久久亚洲| 亚洲精品国产字幕久久不卡| 久久国产免费直播| 久久精品国产69国产精品亚洲| 一本综合久久国产二区| 99久久精品免费看国产| A级毛片无码久久精品免费| 久久AⅤ人妻少妇嫩草影院| 韩国免费A级毛片久久| 无码人妻精品一区二区三区久久久 | 国产精品一区二区久久国产| 国产精品VIDEOSSEX久久发布| 久久人人爽人人爽人人片AV不| 色诱久久av| 麻豆久久| 亚洲伊人久久成综合人影院 | 午夜视频久久久久一区| 国产精久久一区二区三区| 久久综合丁香激情久久| 久久国产精品77777| 久久亚洲春色中文字幕久久久| 久久精品国产99久久久古代| 久久天天躁狠狠躁夜夜avapp| 久久精品无码一区二区日韩AV| 99久久精品国产一区二区三区| 久久香蕉超碰97国产精品| 亚洲av成人无码久久精品| 亚洲成色WWW久久网站| 伊人久久大香线蕉综合影院首页| 久久国产色av免费看| 人妻无码中文久久久久专区|