64 बिट लिनक्स प्रक्रिया के लिए VSIZE इतना बड़ा क्यों है?

Question

मेरा मूल प्रश्न यह है कि 64 बिट प्रक्रिया के लिए VSIZE क्यों 32 बिट के लिए संकलित सटीक उसी प्रोग्राम की तुलना में इतना बड़ा है?

32 बिट प्रक्रिया के लिए/proc/< पिड >/मानचित्र फ़ाइल का आउटपुट निम्न है।

00148000-00149000 r-xp 00000000 00:00 0    [vdso] 
00149000-002d2000 r-xp 00000000 fd:02 8914142   /lib/libc-2.12.so 
002d2000-002d3000 ---p 00189000 fd:02 8914142   /lib/libc-2.12.so 
002d3000-002d5000 r--p 00189000 fd:02 8914142   /lib/libc-2.12.so 
002d5000-002d6000 rw-p 0018b000 fd:02 8914142   /lib/libc-2.12.so 
002d6000-002d9000 rw-p 00000000 00:00 0 
005c9000-005da000 r-xp 00000000 fd:02 17059392  /tmp/vsizetest/lib/libtesting.so 
005da000-005db000 rw-p 00010000 fd:02 17059392  /tmp/vsizetest/lib/libtesting.so 
005db000-0061b000 rw-p 00000000 00:00 0 
00661000-00689000 r-xp 00000000 fd:02 8917713   /lib/libm-2.12.so 
00689000-0068a000 r--p 00027000 fd:02 8917713   /lib/libm-2.12.so 
0068a000-0068b000 rw-p 00028000 fd:02 8917713   /lib/libm-2.12.so 
00694000-006ab000 r-xp 00000000 fd:02 8917680   /lib/libpthread-2.12.so 
006ab000-006ac000 r--p 00016000 fd:02 8917680   /lib/libpthread-2.12.so 
006ac000-006ad000 rw-p 00017000 fd:02 8917680   /lib/libpthread-2.12.so 
006ad000-006af000 rw-p 00000000 00:00 0 
006e5000-00703000 r-xp 00000000 fd:00 3150403   /lib/ld-2.12.so 
00703000-00704000 r--p 0001d000 fd:00 3150403   /lib/ld-2.12.so 
00704000-00705000 rw-p 0001e000 fd:00 3150403   /lib/ld-2.12.so 
00983000-009a0000 r-xp 00000000 fd:02 8914997   /lib/libgcc_s-4.4.5-20110214.so.1 
009a0000-009a1000 rw-p 0001d000 fd:02 8914997   /lib/libgcc_s-4.4.5-20110214.so.1 
00ca5000-00d86000 r-xp 00000000 fd:02 6300601   /usr/lib/libstdc++.so.6.0.13 
00d86000-00d8a000 r--p 000e0000 fd:02 6300601   /usr/lib/libstdc++.so.6.0.13 
00d8a000-00d8c000 rw-p 000e4000 fd:02 6300601   /usr/lib/libstdc++.so.6.0.13 
00d8c000-00d92000 rw-p 00000000 00:00 0 
08048000-08049000 r-xp 00000000 fd:02 21134666  /tmp/vsizetest/bin/testvsz 
08049000-0804a000 rw-p 00000000 fd:02 21134666  /tmp/vsizetest/bin/testvsz 
09b8d000-09bae000 rw-p 00000000 00:00 0    [heap] 
f7796000-f779c000 rw-p 00000000 00:00 0 
ff998000-ff9ae000 rw-p 00000000 00:00 0    [stack] 

कौन सा 3656.

निम्नलिखित की कुल VSIZE में परिणाम है/proc/< पीआईडी ​​>/नक्शे 64 बिट प्रक्रिया के लिए फ़ाइल का उत्पादन होता है।

00400000-00401000 r-xp 00000000 fd:02 21134667    /tmp/vsizetest/bin64/testvsz 
00600000-00601000 rw-p 00000000 fd:02 21134667    /tmp/vsizetest/bin64/testvsz 
02301000-02322000 rw-p 00000000 00:00 0      [heap] 
3b7c800000-3b7c820000 r-xp 00000000 fd:00 661349   /lib64/ld-2.12.so 
3b7ca1f000-3b7ca20000 r--p 0001f000 fd:00 661349   /lib64/ld-2.12.so 
3b7ca20000-3b7ca21000 rw-p 00020000 fd:00 661349   /lib64/ld-2.12.so 
3b7ca21000-3b7ca22000 rw-p 00000000 00:00 0 
3b7cc00000-3b7cd86000 r-xp 00000000 fd:00 661350   /lib64/libc-2.12.so 
3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350   /lib64/libc-2.12.so 
3b7cf86000-3b7cf8a000 r--p 00186000 fd:00 661350   /lib64/libc-2.12.so 
3b7cf8a000-3b7cf8b000 rw-p 0018a000 fd:00 661350   /lib64/libc-2.12.so 
3b7cf8b000-3b7cf90000 rw-p 00000000 00:00 0 
3b7d000000-3b7d083000 r-xp 00000000 fd:00 661365   /lib64/libm-2.12.so 
3b7d083000-3b7d282000 ---p 00083000 fd:00 661365   /lib64/libm-2.12.so 
3b7d282000-3b7d283000 r--p 00082000 fd:00 661365   /lib64/libm-2.12.so 
3b7d283000-3b7d284000 rw-p 00083000 fd:00 661365   /lib64/libm-2.12.so 
3b7d800000-3b7d817000 r-xp 00000000 fd:00 661352   /lib64/libpthread-2.12.so 
3b7d817000-3b7da16000 ---p 00017000 fd:00 661352   /lib64/libpthread-2.12.so 
3b7da16000-3b7da17000 r--p 00016000 fd:00 661352   /lib64/libpthread-2.12.so 
3b7da17000-3b7da18000 rw-p 00017000 fd:00 661352   /lib64/libpthread-2.12.so 
3b7da18000-3b7da1c000 rw-p 00000000 00:00 0 
3b7e000000-3b7e007000 r-xp 00000000 fd:00 661361   /lib64/librt-2.12.so 
3b7e007000-3b7e206000 ---p 00007000 fd:00 661361   /lib64/librt-2.12.so 
3b7e206000-3b7e207000 r--p 00006000 fd:00 661361   /lib64/librt-2.12.so 
3b7e207000-3b7e208000 rw-p 00007000 fd:00 661361   /lib64/librt-2.12.so 
3b87000000-3b87016000 r-xp 00000000 fd:00 664219   /lib64/libgcc_s-4.4.6-20110824.so.1 
3b87016000-3b87215000 ---p 00016000 fd:00 664219   /lib64/libgcc_s-4.4.6-20110824.so.1 
3b87215000-3b87216000 rw-p 00015000 fd:00 664219   /lib64/libgcc_s-4.4.6-20110824.so.1 
3d44c00000-3d44ce8000 r-xp 00000000 fd:00 3019214   /usr/lib64/libstdc++.so.6.0.13 
3d44ce8000-3d44ee8000 ---p 000e8000 fd:00 3019214   /usr/lib64/libstdc++.so.6.0.13 
3d44ee8000-3d44eef000 r--p 000e8000 fd:00 3019214   /usr/lib64/libstdc++.so.6.0.13 
3d44eef000-3d44ef1000 rw-p 000ef000 fd:00 3019214   /usr/lib64/libstdc++.so.6.0.13 
3d44ef1000-3d44f06000 rw-p 00000000 00:00 0 
7f30ab397000-7f30ab39c000 rw-p 00000000 00:00 0 
7f30ab39c000-7f30ab3ad000 r-xp 00000000 fd:02 21127804  /tmp/vsizetest/lib64/libtesting.so 
7f30ab3ad000-7f30ab5ac000 ---p 00011000 fd:02 21127804  /tmp/vsizetest/lib64/libtesting.so 
7f30ab5ac000-7f30ab5ad000 rw-p 00010000 fd:02 21127804  /tmp/vsizetest/lib64/libtesting.so 
7f30ab5ad000-7f30ab5ee000 rw-p 00000000 00:00 0 
7f30ab606000-7f30ab609000 rw-p 00000000 00:00 0 
7fff69512000-7fff69528000 rw-p 00000000 00:00 0    [stack] 
7fff695ff000-7fff69600000 r-xp 00000000 00:00 0    [vdso] 
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall] 

कौन सा 18480.

2 नक्शे के बीच बड़ा अंतर का एक VSIZE में जो परिणाम 64 बिट डेटा से निम्नलिखित प्रविष्टियों हैं:

3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350    /lib64/libc-2.12.so 
3b7d083000-3b7d282000 ---p 00083000 fd:00 661365    /lib64/libm-2.12.so 
3b7d817000-3b7da16000 ---p 00017000 fd:00 661352    /lib64/libpthread-2.12.so 
3b7e007000-3b7e206000 ---p 00007000 fd:00 661361    /lib64/librt-2.12.so 
3b87016000-3b87215000 ---p 00016000 fd:00 664219    /lib64/libgcc_s-4.4.6-20110824.so.1 
3d44ce8000-3d44ee8000 ---p 000e8000 fd:00 3019214   /usr/lib64/libstdc++.so.6.0.13 
7f30ab3ad000-7f30ab5ac000 ---p 00011000 fd:02 21127804  /tmp/vsizetest/lib64/libtesting.so 

18480 की 14316 के लिए कौन-सा खाता VSIZE।

अन्य कार्यक्रमों के साथ अन्य प्रयोग यह दिखाना प्रतीत होता है कि 64 बिट में आपको प्रक्रिया के द्वारा उपयोग की जाने वाली प्रत्येक साझा लाइब्रेरी के लिए स्मृति के इन निजी, गैर-पठनीय, गैर-लिखने योग्य, गैर-निष्पादन योग्य भागों में से एक प्राप्त होता है, जबकि 32 बिट में इन हिस्सों में से कोई भी मुश्किल नहीं है।

क्या किसी को पता है कि स्मृति के ये भाग क्या हैं?

नोट: एक समान प्रश्न के कुछ उत्तरों के आधार पर, What these memory regions for, from a Linux process?, यह एक बहु थ्रेडेड प्रक्रिया नहीं है और यह पहले ही संकलित है-एफपीआईसी।

Answer 1

[वास्तव में एक जवाब ... मेरी जानकारी के अतीत बोल] स्मृति खंडों वास्तव में "निजी, गैर-पठनीय, गैर लिखने योग्य, गैर निष्पादन योग्य" तो वे कभी नहीं करने के लिए भेजा जाना चाहिए रहे हैं, तो और भले ही वे वर्चुअल मेमोरी स्पेस में मौजूद हों, फिर भी वे किसी वास्तविक स्मृति पर कब्जा नहीं करेंगे, और इसलिए चिंता करने के लिए बहुत कुछ नहीं है। (?)

यह किसी प्रकार की पुस्तक-रखरखाव या विखंडन मुद्दा होना चाहिए। चूंकि ये साझा पुस्तकालयों (* .so) का हिस्सा हैं, यह वही है कि उन पुस्तकालयों का निर्माण कैसे किया गया था। वास्तव में आपके प्रोग्राम के साथ कुछ भी नहीं है, इसके अलावा उन पुस्तकालयों से जुड़ा हुआ है। जब तक कि आप उन पुस्तकालयों का पुनर्निर्माण नहीं करना चाहते हैं, या उनका उपयोग नहीं करना चाहते हैं, इसके बारे में बहुत कुछ नहीं करना है (और वैसे भी हासिल करने के लिए बहुत कुछ नहीं है क्योंकि उन्हें किसी भी वास्तविक स्मृति का उपयोग नहीं करना चाहिए)।

शायद संबंधित? What these memory regions for, from a Linux process?

@ कैफ कहते हैं कि कुछ स्मृति खंड "--- पी" हैं "गार्ड पेज" हैं।

इससे पता चलता है कि वे केवल एक भटकने वाले पॉइंटर को पकड़ने के लिए मौजूद हैं या दूर तक त्रुटि में बढ़ रहे हैं ... स्मृति में हार्ड विभाजक की तरह, इसलिए सिस्टम एक सामान्य त्रुटि पकड़ सकता है और उन सामान्य त्रुटियों को छोड़ने के बजाय प्रसंस्करण रोक सकता है (उन्हें संदर्भित करने में यह एक घातक त्रुटि है, और वे वास्तव में कभी भी वास्तविक स्मृति का उपयोग नहीं करेंगे)।

Answer 2

64 बिट साझा लाइब्रेरी में क्यों और किस प्रकार का गठबंधन है, इसका उत्तर देने का उत्तर libc.so लोड करने का उदाहरण ले रहा है और यह लोडर गतिशील पुस्तकालयों को लोड करने के तरीके से देख रहा है।नीचे strace 32 बिट और 64 बिट निष्पादन योग्य दोनों के लिए आउटपुट हैं जो हमें बताता है कि mmap & mprotect पर कॉल हैं।

esunboj@L9AGC12:~/32_64bit$ strace ./crash-x86-64 
... 
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"..., 
832) = 832 
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0 
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =  
0x7fa354f8a000 
mprotect(0x7fa35513f000, 2093056, PROT_NONE) = 0 
mmap(0x7fa35533e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 
3, 0x1b4000) = 0x7fa35533e000 
mmap(0x7fa355344000, 17624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x7fa355344000 
close(3)        = 0 
... 

esunboj@L9AGC12:~/32_64bit$ strace ./crash 
... 
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\226\1\0004\0\0\0"..., 
512) = 512 
fstat64(3, {st_mode=S_IFREG|0755, st_size=1730024, ...}) = 0 
mmap2(NULL, 1743580, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xfffffffff7546000 
mprotect(0xf76e9000, 4096, PROT_NONE) = 0 
mmap2(0xf76ea000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 
3, 0x1a3) = 0xfffffffff76ea000 
mmap2(0xf76ed000, 10972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0xfffffffff76ed000 
close(3)        = 0 
... 

बारीकी से, को देख दोनों strace के दो बातों की छानबीन करने की आवश्यकता कर रहे हैं

1. उनमें से प्रत्येक नक्शे स्मृति 3 बार और mprotect को 1 कॉल बिल्कुल के बाद पहली mmap ।

2. 64 बिट & 32 बिट के लिए mprotect कॉल की तुलना 2093056B & क्षेत्र क्रमशः संरक्षित की 4096B है।

dl-load.c में, सबरूटीन _dl_map_object_from_fd() आवश्यक अनुमतियों की स्थापना करके आभासी अंतरिक्ष के लिए गतिशील पुस्तकालय स्मृति क्षेत्रों के नक्शे और शून्य पुस्तकालय की .bss अनुभाग भर जाता है और लिंक नक्शा संरचना अद्यतन करता है। अधिक विश्लेषण के लिए यहाँ कोड का कुछ हिस्सा प्राप्त करने देता है,

struct link_map * 
_dl_map_object_from_fd () 
{ 
... 
    /* Scan the program header table, collecting its load commands. */ 
    struct loadcmd 
    { 
    ElfW(Addr) mapstart, mapend, dataend, allocend; 
    off_t mapoff; 
    int prot; 
    } loadcmds[l->l_phnum], *c; // l is link_map struct described for each object 
            of dynamic linker 
    size_t nloadcmds = 0; 
    bool has_holes = false; 
    ... 
    for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) 
    switch (ph->p_type) 
    { 
    ... 
    case PT_LOAD: 
    ... 
    c = &loadcmds[nloadcmds++]; 
    c->mapstart = ph->p_vaddr & ~(GLRO(dl_pagesize) - 1); 
    c->mapend = ((ph->p_vaddr + ph->p_filesz + GLRO(dl_pagesize) - 1) 
        & ~(GLRO(dl_pagesize) - 1)); 
    ... 
    if (nloadcmds > 1 && c[-1].mapend != c->mapstart) 
     has_holes = true; 
    ... 
    } 
    ... 
    if (has_holes) 
     __mprotect ((caddr_t) (l->l_addr + c->mapend), 
      loadcmds[nloadcmds - 1].mapstart - c->mapend, PROT_NONE); 
    ... 
} 

ऊपर कोड l_phnumfor बयान में प्रयोग किया जाता में ELF कार्यक्रम शीर्षक में प्रविष्टियों की संख्या रखती है। आदर्श रूप से प्रत्येक पुनरावृत्ति के लिए प्रत्येक प्रविष्टि सेगमेंट मैप किए जाते हैं। PT_LOAD खंड मामले में अपनी पहली बार है, इसके मूल रूप से एक .text या .rodata अनुभाग जो mmapped हो जाता है (mmap 1 strace में) और दूसरे PT_LOAD खंड के लिए हिट जब .data अनुभाग मैप किया जाता है (strace में 2 mmap) का प्रतिनिधित्व करता है। दूसरा PT_LOAD सेगमेंट मैप किया गया है, mapstart और mapend संरक्षित है जो टेक्स्ट सेक्शन के प्रारंभ और अंत को संदर्भित करता है। अगले PT_LOAD पुनरावृत्ति अगर पिछले सेगमेंट mapend वर्तमान (.डेटा) सेगमेंट mapstart के बराबर नहीं है तो यह दो PT_LOAD सेगमेंट (.text और .data अनुभागों के बीच अंतर) के बीच एक छेद है। इसलिए, यदि उनके पास शून्य अनुमतियों वाले स्मृति क्षेत्रों के बीच एक छेद है, तो लोडर (mprotect स्ट्रेस में कॉल) की रक्षा करेगा या इसे पहुंच से बाहर कर देगा। 64 बिट और 32 बिट प्रक्रिया के लिए संरक्षित क्षेत्र बनाम पृष्ठ क्रमश: 64 बिट पुस्तकालयों के लिए विशाल मेमोरी खंड में जोड़ रहा है। 64 बिट दुर्गम क्षेत्र के लिए

सबूत: libc.so के लिए objdump नीचे हमें कुछ आभासी पता (VA) के आंकड़े जो उचित रूप से roundoff इस प्रकार हैं, देता

    PT_LOAD(1)    PT_LOAD(2)      
mapstart VA 0x0000000000000000  0x00000000003b4000 
mapend VA 0x00000000001b5000  0x00000000003A0000 

यहाँ PT_LOAD(1) mapend (0x00000000001b5000) PT_LOAD(2) mapstart के बराबर नहीं है (0x00000000003b4000) जिसके परिणामस्वरूप 0x00000000001FF000 का मेमोरी होल (दशमलव 2093056B में)।

esunboj@L9AGC12:~/32_64bit$objdump -x -s -d -D /lib/x86_64-linux-gnu/libc.so.6 
Program Header: 
... 
    LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**21 
     filesz 0x00000000001b411c memsz 0x00000000001b411c flags r-x 
    LOAD off 0x00000000001b4700 vaddr 0x00000000003b4700 paddr 0x00000000003b4700 align 2**21 
     filesz 0x0000000000005160 memsz 0x0000000000009dd8 flags rw- 
... 

शीर्ष 64 बिट पाठ पर ले जाता है शिक्षा का एक उच्च प्रतिनिधित्व 32 बिट की तुलना में बाइट्स। इसी तरह 64 बिट पर पॉइंटर्स का आकार 8B4 और बाइट जोड़ रहा है।इसके अलावा डेटा स्ट्रक्चर संरेखण एक 8B 64 बिट बनाने वाले मैप किए गए क्षेत्रों में गठबंधन है। बाइनरी पर

सरल size आदेश के रूप में नीचे 32/64 बिट कार्यक्रमों स्मृति क्षेत्रों के बीच का अंतर दिखा सकते हैं,

esunboj@L9AGC12:~/32_64bit$ ls -lrt 
total 10368 
-rwxrwxrwx 1 esunboj ei 5758776 Oct 10 11:35 crash-x86-64 
-rwxrwxrwx 1 esunboj ei 4855676 Oct 10 11:36 crash 
esunboj@L9AGC12:~/32_64bit$ size crash 
    text data  bss  dec  hex filename 
4771286 82468 308704 5162458 4ec5da crash 
esunboj@L9AGC12:~/32_64bit$ size crash-x86-64 
    text data  bss  dec  hex filename 
5634861 121164 1623728 7379753 709b29 crash-x86-64 

Answer 3

प्रमुख VSIZE अंतर से कैसे PROT_NONE मैपिंग (मोड "--- पी") आता है साझा पुस्तकालयों के 32-बिट और 64-बिट संस्करणों के मामले में किया जाता है।

ये वास्तव में मैपिंग हैं जिन्हें आपने अंतर पैदा करने के रूप में देखा है।

प्रत्येक शेयर की गई लाइब्रेरी के लिए सामान्य तौर पर लोड हम चार मैपिंग करना होगा:

3b7cc00000-3b7cd86000 r-xp 00000000 fd:00 661350   /lib64/libc-2.12.so 
3b7cd86000-3b7cf86000 ---p 00186000 fd:00 661350   /lib64/libc-2.12.so 
3b7cf86000-3b7cf8a000 r--p 00186000 fd:00 661350   /lib64/libc-2.12.so 
3b7cf8a000-3b7cf8b000 rw-p 0018a000 fd:00 661350   /lib64/libc-2.12.so 

पहले एक निष्पादन योग्य अनुमतियों के साथ कोड खंड, दूसरा PROT_NONE (मोड ---) मानचित्रण (पृष्ठों नहीं हो सकता है एक्सेस किया जा सकता है), और पिछले दो डेटा सेगमेंट (केवल भाग पढ़ते हैं और लिखते हैं)।

PROT_NONE का आकार MAXPAGESIZE है और इसलिए यह 32-बिट और 64-बिट संस्करणों में अलग-अलग बनाया गया है। 32-बिट संस्करण के मामले में इसमें 4 केबी आकार (i386 के लिए MAXPAGESIZE) और 64-बिट संस्करण 2 एमबी (x86_64 सिस्टम के लिए मानक MAXPAGESIZE) के मामले में है।

यह ध्यान दिया जाना चाहिए कि इस स्मृति वास्तव में भस्म नहीं है (यह सिर्फ पता स्थान के पते की खपत) के रूप में यहाँ का उल्लेख किया:

http://www.greenend.org.uk/rjk/tech/dataseg.html

"यह अतिरिक्त आप किसी भी RAM या स्वैप खर्च नहीं करना पड़ता अंतरिक्ष, बस प्रत्येक प्रक्रिया के भीतर पता स्थान, जो 64-बिट प्लेटफार्मों पर भरपूर आपूर्ति में है। अंतर्निहित कारण पुस्तकालयों को कुशलतापूर्वक तेज़ रखने के साथ करना है, लेकिन कार्यान्वयन थोड़ा अजीब है। "

pmap <PID> 

बढ़ाया के लिए:

बुनियादी जानकारी के लिए:

बस एक आखिरी चाल, मैं pmap उपयोगिता का उपयोग करने से नक्शे फ़ाइल पार्स करके एक सरल पढ़ने के लिए उत्पादन का उत्पादन स्मृति मैपिंग जांच करने के लिए आसान लगता है जानकारी:

pmap -x <PID>