अधिकांश सी संकलक आपको अपरिभाषित सीमाओं के साथ extern सरणी तक पहुंचने की अनुमति देते हैं, उदाहरण के लिए:

 extern int external_array[]; int array_get (long int index) { return external_array[index]; } 

External_array की परिभाषा किसी अन्य अनुवाद इकाई में हो सकती है और इस तरह दिख सकती है:

 int external_array[3] = { 1, 2, 3 }; 

सवाल यह है कि अगर यह अलग परिभाषा इस तरह बदलती है तो क्या होता है:

 int external_array[4] = { 1, 2, 3, 4 }; 

या तो:

 int external_array[2] = { 1, 2 }; 

क्या बाइनरी इंटरफ़ेस संरक्षित किया जाएगा (बशर्ते कि एक तंत्र है जो एप्लिकेशन को रन समय पर सरणी के आकार को निर्धारित करने की अनुमति देता है)?

उत्सुकता से, कई आर्किटेक्चर पर, सरणी का आकार बढ़ाना द्विआधारी इंटरफ़ेस संगतता (एबीआई) का उल्लंघन करता है। सरणी का आकार कम करने से संगतता समस्याएं भी हो सकती हैं। इस लेख में, हम एबीआई संगतता पर एक करीब से नज़र रखेंगे और बताएंगे कि समस्याओं से कैसे बचा जाए।

निष्पादन योग्य फ़ाइल के डेटा अनुभाग में लिंक

यह समझने के लिए कि सरणी का आकार बाइनरी इंटरफ़ेस का हिस्सा कैसे बनता है, हमें सबसे पहले निष्पादन योग्य फ़ाइल के डेटा अनुभाग में लिंक की जांच करने की आवश्यकता है। बेशक, विवरण विशिष्ट वास्तुकला पर निर्भर करता है, और यहां हम x86-64 वास्तुकला पर ध्यान केंद्रित करेंगे।

X86-64 आर्किटेक्चर प्रोग्राम काउंटर के सापेक्ष संबोधित करने का समर्थन करता है, जो कि, वैश्विक सरणी चर तक पहुंच है, जैसा कि पहले दिखाए गए array_get फ़ंक्शन में किया जा सकता है, एक एकल movl निर्देश में संकलित किया जा सकता है:

 array_get: movl external_array(,%rdi,4), %eax ret 

इससे, कोडांतरक एक ऑब्जेक्ट फ़ाइल बनाता है जिसमें निर्देश R_X86_64_32S के रूप में चिह्नित R_X86_64_32S ।

 0000000000000000 : 0: mov 0x0(,%rdi,4),%eax 3: R_X86_64_32S external_array 7: retq 

यह चाल लिंकर ( ld ) को बताती है कि निष्पादन योग्य बनाते समय लिंकिंग के दौरान external_array चर के संबंधित स्थान को कैसे पॉपुलेट किया जाए।

इसके दो महत्वपूर्ण परिणाम हैं।

• चूंकि चर की ऑफसेट निर्माण समय पर निर्धारित की जाती है, रन समय पर इसे निर्धारित करने के लिए कोई ओवरहेड नहीं होता है। केवल मूल्य ही स्मृति तक पहुंच है।
  
• ऑफसेट को निर्धारित करने के लिए, आपको सभी चर डेटा के आकारों को जानना होगा। अन्यथा, लेआउट के दौरान डेटा अनुभाग के प्रारूप की गणना करना असंभव होगा।

सी कार्यान्वयन के लिए GNU / Linux के रूप में निष्पादन योग्य और लिंक प्रारूप (ELF) के लिए उन्मुख, extern चर के संदर्भ में ऑब्जेक्ट आकार नहीं होते हैं। array_get उदाहरण में array_get ऑब्जेक्ट का आकार संकलक के लिए भी अज्ञात है। वास्तव में, पूरी असेंबलर फाइल इस तरह दिखती है ( -fno-asynchronous-unwind-tables से केवल प्रचार जानकारी को -fno-asynchronous-unwind-tables , जो तकनीकी रूप से psabi अनुपालन के लिए आवश्यक है):

  .file "get.c" .text .p2align 4,,15 .globl array_get .type array_get, @function array_get: movl external_array(,%rdi,4), %eax ret .size array_get, .-array_get .ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)" .section .note.GNU-stack,"",@progbits 

इस कोडांतरक फ़ाइल में external_array लिए कोई आकार की जानकारी नहीं है: एकमात्र चरित्र संदर्भ movl अनुदेश के साथ लाइन पर है, और अनुदेश में केवल संख्यात्मक डेटा सरणी तत्व का आकार है (जो कि movl गुणा 4 से गुणा किया गया है)।

यदि ELF को अपरिभाषित चर के लिए आकार की आवश्यकता होती है, तो array_get फ़ंक्शन को संकलित करना भी असंभव होगा।

लिंकर को वास्तविक चरित्र आकार कैसे मिलता है? वह प्रतीक की परिभाषा को देखता है और वहां मिलने वाली आकार की जानकारी का उपयोग करता है। यह कंपाइलर को डेटा अनुभाग के लेआउट की गणना करने और उचित ऑफसेट के साथ डेटा आंदोलनों को भरने की अनुमति देता है।

आम ELF ऑब्जेक्ट्स

ईएलएफ के लिए सी कार्यान्वयन को प्रोग्रामर को स्रोत कोड मार्कअप को जोड़ने की आवश्यकता नहीं है यह इंगित करने के लिए कि क्या कोई फ़ंक्शन या चर वर्तमान ऑब्जेक्ट (जो लाइब्रेरी या मुख्य निष्पादन योग्य हो सकता है) या किसी अन्य ऑब्जेक्ट में स्थित है। लिंकर और डायनेमिक लोडर इस बात का ध्यान रखेंगे।

उसी समय, निष्पादन योग्य फ़ाइलों की इच्छा थी कि संकलन मॉडल को बदलकर प्रदर्शन को कम न किया जाए। इसका मतलब यह है कि जब मुख्य कार्यक्रम के लिए स्रोत कोड को संकलित किया जाता है (जो कि -fPIC बिना है, और इस विशेष मामले में -fPIE बिना), array_get फ़ंक्शन array_get गतिशील साझा किए गए ऑब्जेक्ट को प्रस्तुत करने से पहले कमांड के बिल्कुल उसी क्रम में संकलित किया जाता है । इसके अलावा, इससे कोई फर्क नहीं पड़ता कि सबसे external_array निष्पादन योग्य फ़ाइल में external_array वैरिएबल को परिभाषित किया गया है या रन टाइम पर अलग से कोई साझा ऑब्जेक्ट लोड किया गया है। कंपाइलर द्वारा बनाए गए निर्देश दोनों ही मामलों में समान हैं।

यह कैसे संभव है? आखिरकार, आम ईएलएफ ऑब्जेक्ट स्थिति-स्वतंत्र होते हैं। वे रनटाइम पर अप्रत्याशित, यादृच्छिक पते पर लोड किए जाते हैं। हालाँकि, कंपाइलर एक मशीन कोड अनुक्रम बनाता है जिसके लिए प्रोग्राम शुरू होने से बहुत पहले, इन वेरिएबल्स को लिंक करने के दौरान गणना की गई निश्चित ऑफसेट पर स्थित होने की आवश्यकता होती है।

तथ्य यह है कि केवल एक लोड की गई वस्तु (मुख्य निष्पादन योग्य फ़ाइल) इन निश्चित ऑफसेट का उपयोग करती है। अन्य सभी ऑब्जेक्ट (डायनेमिक लोडर स्वयं, सी रनटाइम लाइब्रेरी और प्रोग्राम द्वारा उपयोग की जाने वाली अन्य लाइब्रेरी) पूरी तरह से स्थिति-स्वतंत्र ऑब्जेक्ट (PICs) के रूप में संकलित और संकलित हैं। ऐसी वस्तुओं के लिए, कंपाइलर वैश्विक ऑफसेट तालिका (GOT) से प्रत्येक चर का वास्तविक पता लोड करता है। हम इस राउंडअबाउट को देख सकते हैं अगर हम array_get साथ -fPIC उदाहरण संकलित करते हैं, जो इस तरह के विधानसभा कोड की ओर जाता है:

 array_get: movq external_array@GOTPCREL(%rip), %rax movl (%rax,%rdi,4), %eax ret 

नतीजतन, external_array वैरिएबल का पता अब हार्डकोड नहीं है और इसे GOT रिकॉर्ड को उचित रूप से प्रारंभ करके रन टाइम में बदला जा सकता है। इसका मतलब यह है कि रन टाइम में, external_array की परिभाषा उसी साझा ऑब्जेक्ट, किसी अन्य साझा ऑब्जेक्ट या मुख्य प्रोग्राम में हो सकती है। गतिशील लोडर ईएलएफ चरित्र खोज नियमों के आधार पर उपयुक्त परिभाषा खोजेगा और जीओटी रिकॉर्ड को उसके वास्तविक पते पर अपडेट करके उसकी परिभाषा के साथ अपरिभाषित प्रतीक संदर्भ को जोड़ देगा।

हम मूल उदाहरण पर array_get , जहां array_get फ़ंक्शन मुख्य कार्यक्रम में है, इसलिए चर का पता सीधे निर्दिष्ट किया गया है। लिंकर में लागू किया गया मुख्य विचार यह है कि मुख्य कार्यक्रम एक external_array चर परिभाषा प्रदान करेगा, भले ही यह वास्तव में रनटाइम में एक सामान्य वस्तु में परिभाषित किया गया हो । साझा किए गए ऑब्जेक्ट में चर की प्रारंभिक परिभाषा को निर्दिष्ट करने के बजाय, डायनेमिक लोडर निष्पादन योग्य फ़ाइल के डेटा अनुभाग में चर की एक प्रति का चयन करेगा।

इसके दो महत्वपूर्ण परिणाम हैं। सबसे पहले, याद रखें कि external_array को निम्नानुसार परिभाषित किया गया है:

 int external_array[3] = { 1, 2, 3 }; 

यहां एक इनिशलाइज़र है जिसे मुख्य निष्पादन योग्य फ़ाइल में परिभाषा पर लागू किया जाना चाहिए। ऐसा करने के लिए, मुख्य निष्पादन योग्य फ़ाइल में, प्रतीक की प्रतिलिपि प्रतिलिपि स्थान के लिए एक लिंक रखा गया है। readelf -rW इसे R_X86_64_COPY रूप में R_X86_64_COPY ।

  0x408 ऑफसेट पर '' .rela.dyn 'खंड 3 प्रविष्टियों में शामिल हैं:
     ऑफसेट जानकारी टाइप सिंबल की वैल्यू सिंबल का नाम + एडेंड
 0000000000403ff0 0000000100000006 R_X86_64_GLOB_DAT 0000000000000000 __libc_start_main@GLIBC_2.2.5 + 0
 0000000000403ff8 0000000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
 0000000000404020 0000000300000005 R_X86_64_COPY 0000000000404020 external_array + 0 

अन्य आंदोलनों की तरह, कॉपी मूवमेंट को डायनेमिक लोडर द्वारा नियंत्रित किया जाता है। इसमें एक सरल, बिटवाइज़ कॉपी ऑपरेशन शामिल है। कॉपी का लक्ष्य विस्थापन ऑफसेट (उदाहरण में 0000000000404020 ) से निर्धारित होता है। स्रोत को रनटाइम पर प्रतीक नाम ( external_array ) और उसके मान के आधार पर निर्धारित किया जाता है। प्रतिलिपि बनाते समय, डायनेमिक लोडर को बाइट्स की संख्या प्राप्त करने के लिए चरित्र के आकार को भी देखना होगा जिसे कॉपी करने की आवश्यकता है। यह सब संभव बनाने के लिए, external_array प्रतीक स्वचालित रूप से निष्पादन योग्य फ़ाइल से एक विशिष्ट प्रतीक के रूप में निर्यात किया जाता है ताकि यह रन समय में गतिशील लोडर को दिखाई दे। डायनामिक सिंबल टेबल ( .dynsym ) इसे प्रतिबिंबित करता है, जैसा कि readelf -sW कमांड द्वारा दिखाया गया है:

  प्रतीक तालिका '.dynsym' में 4 प्रविष्टियाँ हैं:
    संख्या: मान आकार प्रकार बाइंड विज़ निडक्स नाम
      0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 
      1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
      2: 0000000000000000 0 नोट नहीं जारी किए गए अंक __gmon_start__
      3: 0000000000404020 12 ओब्जैक्ट ग्लोबल डिफॉल्ट 22 एक्सटर्नल_अरे 

ऑब्जेक्ट के आकार के बारे में जानकारी कहां से आती है (12 बाइट्स, इस उदाहरण में)? लिंकर सभी सामान्य वस्तुओं को खोलता है, इसकी परिभाषा खोजता है और आकार के बारे में जानकारी लेता है। पहले की तरह, यह लिंकर को डेटा अनुभाग के लेआउट की गणना करने की अनुमति देता है ताकि निश्चित ऑफसेट का उपयोग किया जा सके। फिर से, मुख्य निष्पादन योग्य में परिभाषा का आकार तय किया गया है और उसे रन टाइम पर नहीं बदला जा सकता है।

डायनामिक लिंकर साझा ऑब्जेक्ट्स में प्रतीकात्मक लिंक को मुख्य निष्पादन योग्य में स्थानांतरित कॉपी पर पुनर्निर्देशित भी करता है। यह सुनिश्चित करता है कि पूरे कार्यक्रम में चर की केवल एक प्रति है, जैसा कि सी भाषा के शब्दार्थों की आवश्यकता होती है। अन्यथा, यदि वैरिएशन के बाद परिवर्तन होता है, तो मुख्य निष्पादन योग्य फ़ाइल से अपडेट गतिशील साझा ऑब्जेक्ट और इसके विपरीत दिखाई नहीं देगा।

बाइनरी संगतता पर प्रभाव

यदि हम मुख्य कार्यक्रम को लिंक किए बिना (या पुनर्नवीनीकरण) साझा किए गए ऑब्जेक्ट में external_array की परिभाषा को बदलते हैं तो क्या होता है? सबसे पहले, एक सरणी तत्व जोड़ने पर विचार करें।

 int external_array[4] = { 1, 2, 3, 4 }; 

यह रनटाइम में डायनेमिक लोडर से एक चेतावनी उत्पन्न करेगा:

main-program: Symbol `external_array' has different size in shared object, consider re-linking

मुख्य कार्यक्रम में अभी भी केवल 12 बाइट्स के लिए external_array साथ एक external_array परिभाषा है। इसका मतलब यह है कि प्रतिलिपि अधूरी है: सरणी के केवल पहले तीन तत्व कॉपी किए गए हैं। परिणामस्वरूप, सरणी तत्व extern_array[3] तक पहुंच को परिभाषित नहीं किया गया है। यह दृष्टिकोण न केवल मुख्य कार्यक्रम को प्रभावित करता है, बल्कि प्रक्रिया में पूरे कोड को भी प्रभावित करता है, क्योंकि extern_array सभी संदर्भ मुख्य कार्यक्रम में परिभाषा पर पुनर्निर्देशित किए गए थे। इसमें एक सामान्य ऑब्जेक्ट शामिल है जो एक extern_array परिभाषा प्रदान करता है। वह शायद ऐसी स्थिति का सामना करने के लिए तैयार नहीं है, जहां उसकी परिभाषा में एक सरणी तत्व गायब हो गया है।

किसी तत्व को हटाने के विपरीत दिशा में बदलने के बारे में कैसे?

 int external_array[2] = { 1, 2 }; 

यदि प्रोग्राम एरे तत्व को extern_array[2] तक पहुंचने से extern_array[2] , क्योंकि यह किसी तरह एरे की कम लंबाई का पता लगाता है, तो यह काम करेगा। सरणी के बाद, कुछ अप्रयुक्त मेमोरी है, लेकिन यह प्रोग्राम को नहीं तोड़ देगा।

इसका मतलब यह है कि हमें निम्नलिखित नियम मिलते हैं:

• वैश्विक सरणी चर में तत्वों को जोड़ने से द्विआधारी संगतता का उल्लंघन होता है।
  
• हटाए जाने वाले आइटमों को हटाए जाने की व्यवस्था से बचने वाला कोई तंत्र न होने पर आइटम निकालना संगतता को तोड़ सकता है।

दुर्भाग्य से, गतिशील लोडर की चेतावनी वास्तव में की तुलना में अधिक हानिरहित दिखती है, और दूरदराज के तत्वों के लिए बिल्कुल भी चेतावनी नहीं है।

इस स्थिति से कैसे बचा जाए

एबीआई परिवर्तनों का पता लगाना लिम्बिगेल जैसे उपकरणों के साथ काफी आसान है।

इस स्थिति से बचने का सबसे आसान तरीका एक फ़ंक्शन को लागू करना है जो सरणी का पता देता है:

 static int local_array[3] = { 1, 2, 3 }; int * get_external_array (void) { return local_array; } 

यदि लाइब्रेरी में उपयोग किए जाने के तरीके के कारण सरणी की परिभाषा को स्थिर नहीं बनाया जा सकता है, तो इसके बजाय हम इसकी दृश्यता को छिपा सकते हैं और इसके निर्यात को भी रोक सकते हैं और इसलिए, कटाव समस्या से बचें:

 int local_array[3] __attribute__ ((visibility ("hidden"))) = { 1, 2, 3 }; 

सब कुछ बहुत अधिक जटिल है अगर सरणी चर पिछड़े संगतता कारणों के लिए निर्यात किया जाता है। चूंकि लाइब्रेरी से सरणी को छोटा किया गया है, इसलिए एक छोटी सरणी परिभाषा वाला पुराना मुख्य कार्यक्रम नए क्लाइंट कोड के लिए पूर्ण सरणी तक पहुंच प्रदान करने में सक्षम नहीं होगा यदि यह उसी वैश्विक सरणी के साथ उपयोग किया जाता है। इसके बजाय, एक्सेस फ़ंक्शन एक अलग (स्टैटिक या हिडन) ऐरे का उपयोग कर सकता है, या अंत में अतिरिक्त तत्वों के लिए एक अलग ऐरे का उपयोग कर सकता है। नुकसान यह है कि सब कुछ एक निरंतर सरणी में संग्रहीत करना संभव नहीं है अगर सरणी चर पिछड़े संगतता के लिए निर्यात किया जाता है। माध्यमिक इंटरफ़ेस का डिज़ाइन इसे प्रतिबिंबित करना चाहिए।

वर्णों के संस्करण नियंत्रण का उपयोग करके, आप कई संस्करणों को विभिन्न आकारों के साथ निर्यात कर सकते हैं, कभी भी किसी विशेष संस्करण में आकार नहीं बदल सकते। इस मॉडल का उपयोग करते हुए, नए संबंधित कार्यक्रम हमेशा नवीनतम संस्करण का उपयोग करेंगे, संभवतः सबसे बड़े आकार के साथ। चूंकि प्रतीक के संस्करण और आकार एक ही समय में लिंक संपादक द्वारा तय किए जाते हैं, वे हमेशा सुसंगत होते हैं। GNU C लाइब्रेरी ऐतिहासिक चर sys_errlist और sys_siglist लिए इस दृष्टिकोण का उपयोग sys_siglist । हालाँकि, यह अभी भी एक भी निरंतर सरणी प्रदान नहीं करता है।

सभी चीजें मानी जाती हैं, एक get_external_array फ़ंक्शन (उदाहरण के लिए, get_external_array फ़ंक्शन ऊपर) इस ABI संगतता समस्या से बचने के लिए सबसे अच्छा तरीका है।