यह ज्ञात है कि .bs अनुभाग डिस्क में संग्रहीत नहीं किया गया था, लेकिन स्मृति में .bss खंड को शून्य में प्रारंभ किया जाना चाहिए। लेकिन स्मृति में इसे कहाँ लेना चाहिए? क्या ईएलएफ हेडर में प्रदर्शित कोई जानकारी है या क्या .bss अनुभाग डेटा अनुभाग के आगे दिखाई देने की संभावना है, या कुछ और ??ईएलएफ फ़ाइल के .bss अनुभाग को स्मृति में कहाँ लेना चाहिए?
पता करने के लिए जहां बीएसएस खंड स्मृति में हो जाएगा, यह readelf -S program चलाते हैं, और की जाँच करने के लिए पर्याप्त है .bss पंक्ति पर Addr कॉलम।
ज्यादातर मामलों में, आप यह भी देखेंगे कि प्रारंभिक डेटा अनुभाग (.data) तुरंत पहले आता है। यही है, आप देखेंगे कि .data अनुभाग में Addr + Size अनुभाग .bss अनुभाग के प्रारंभिक पते से मेल खाता है।
हालांकि, यह हमेशा आवश्यक नहीं है। ये ऐतिहासिक सम्मेलन हैं, और ELF specification (प्लेटफार्म विशिष्ट पूरक के साथ पढ़ने के लिए, उदाहरण के लिए 32-bit x86 machines को कवर करने वाले अध्याय 5 में) अधिक परिष्कृत कॉन्फ़िगरेशन की अनुमति देता है, और उन सभी को लिनक्स द्वारा समर्थित नहीं किया जाता है।
उदाहरण के लिए, अनुभाग को .bss कहा जा सकता है। केवल 2 गुण है कि एक बीएसएस अनुभाग में इस तरह कर रहे हैं:
SHT_NOBITS के साथ चिह्नित है (जो है, यह स्मृति में अंतरिक्ष ले जाता है, लेकिन भंडारण पर कोई नहीं) जो readelf के उत्पादन में NOBITS के रूप में दिखाई देता है।PT_LOAD), पठनीय (PF_R), और लिखने योग्य (PF_W) सेगमेंट के लिए मानचित्र करता है। इस तरह का एक सेगमेंट मेमोरी (p_filesz < p_memsz) की तुलना में स्टोरेज पर भी छोटा है।आप एक से अधिक बीएसएस वर्गों हो सकता है: PowerPC निष्पादनयोग्य .sbss और .sbss2 अप्रारंभीकृत डेटा चर के लिए हो सकता है।
अंत में, बीएसएस अनुभाग आवश्यक रूप से डेटा अनुभाग या ढेर के निकट नहीं है। यदि आप Linux kernel (विशेष रूप से load_elf_binary फ़ंक्शन में अधिक) की जांच करते हैं तो आप देख सकते हैं कि बीएसएस अनुभाग (या अधिक सटीक, segment यह मानचित्र करता है) को कोड और प्रारंभिक डेटा के साथ भी अंतःस्थापित किया जा सकता है। लिनक्स कर्नेल इसे हल करने का प्रबंधन करता है।
बीएसएस डेटा और ढेर के बीच है, जैसा कि this marvelous article में विस्तृत है।
आप size का उपयोग कर प्रत्येक अनुभाग के आकार पता कर सकते हैं:
[email protected]:~$ size try
text data bss dec hex filename
1108 496 16 1620 654 try
yep +1 उस आलेख के लिए आपने वास्तव में एक महान पोस्ट किया है – abhi
+1 क्या आप अभी भी 32 बिट दादाजी पर हैं? – JeremyP
सभी 64 बिट प्रचार समाप्त होने की प्रतीक्षा :-)) – cnicutar