सी / सी ++ में निर्धारक विधानसभाओं का परिचय। भाग 1

लेख का अनुवाद विशेष रूप से पाठ्यक्रम "C ++ डेवलपर" के छात्रों के लिए तैयार किया गया था।

---

निर्धारक विधानसभा क्या है?

एक नियतात्मक विधानसभा एक ही पर्यावरण और विधानसभा निर्देशों के साथ एक ही स्रोत कोड के निर्माण की प्रक्रिया है, जिसमें एक ही बाइनरी फाइलें किसी भी मामले में बनाई जाती हैं, भले ही वे विभिन्न मशीनों पर, विभिन्न निर्देशिकाओं में और विभिन्न नामों के साथ बनाई गई हों । ऐसी असेंबली को कभी-कभी खेलने योग्य या सीलबंद असेंबली के रूप में भी संदर्भित किया जाता है, अगर यह गारंटी दी जाती है कि वे विभिन्न फ़ोल्डरों से संकलन करते समय भी समान बायनेरिज़ बनाएंगे।

नियतात्मक विधानसभाएं ऐसी चीज नहीं हैं जो अपने आप होती हैं। वे साधारण परियोजनाओं में नहीं बनाए जाते हैं, और ऐसा नहीं होने के कारण प्रत्येक ऑपरेटिंग सिस्टम या कंपाइलर के लिए भिन्न हो सकते हैं।

नियत विधानसभाओं को एक निर्धारित विधानसभा वातावरण के लिए गारंटी दी जानी चाहिए। इसका मतलब है कि कुछ चर, जैसे ऑपरेटिंग सिस्टम, सिस्टम संस्करण का निर्माण, और लक्ष्य वास्तुकला , संभवतः विभिन्न बिल्ड में समान हैं।

हाल के वर्षों में, विभिन्न संगठनों, जैसे क्रोमियम , रिप्रोड्यूसबल बिल्ड्स, या योक्टो , ने निर्धारक विधानसभाओं को प्राप्त करने के लिए बहुत प्रयास किए हैं।

निर्धारक विधानसभाओं का महत्व

निर्धारक विधानसभाओं के महत्वपूर्ण होने के दो मुख्य कारण हैं:

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

सी / सी ++ में निर्माण प्रक्रिया में शामिल बाइनरी फाइलें

ऑपरेटिंग सिस्टम के आधार पर, C / C ++ में बिल्ड प्रक्रिया के दौरान बनाए जाने वाले विभिन्न प्रकार के बायनेरिज़ हैं।

माइक्रोसॉफ्ट विंडोज सबसे महत्वपूर्ण एक्सटेंशन .obj , .lib साथ फाइलें हैं .lib dll और .exe । वे सभी पोर्टेबल निष्पादन योग्य (पीई) प्रारूप विनिर्देश का अनुपालन करते हैं। इन फाइलों का डंपबिन जैसे उपकरणों के साथ विश्लेषण किया जा सकता है।
लिनक्स। एक्सटेंशन .o , .a , .so और बिना एक्सटेंशन वाली फाइलें (एक्जीक्यूटेबल बाइनरी फाइल के लिए) एक्जीक्यूटेबल और कंपोजेबल फाइल (एक्जिक्यूटेबल और लिंकेबल फॉर्मेट, ईएलएफ) के प्रारूप के अनुरूप होती हैं। ELF फ़ाइलों की सामग्री का उपयोग करके विश्लेषण किया जा सकता है।
मैक ओएस एक्सटेंशन वाली फाइलें .o , .a , .dylib और बिना एक्सटेंशन वाली (एक्जीक्यूटेबल बाइनरी फाइल के लिए) माच-ओ फॉर्मेट स्पेसिफिकेशन का पालन करती हैं। इन फ़ाइलों को ओटूल एप्लिकेशन का उपयोग करके सत्यापित किया जा सकता है, जो मैकओएस पर एक्सकोड टूलकिट का हिस्सा है।

विविधताओं के स्रोत

कई अलग-अलग कारक आपकी विधानसभाओं को गैर-नियतात्मक बना सकते हैं। विभिन्न ऑपरेटिंग सिस्टम और कंपाइलर के लिए कारक अलग-अलग होंगे। प्रत्येक कंपाइलर में भिन्नता के स्रोतों को ठीक करने के लिए कुछ पैरामीटर हैं। आज तक, gcc और clang ऐसे कंपाइलर हैं जिनमें फिक्सिंग के अधिक विकल्प होते हैं। msvc लिए कुछ msvc विकल्प हैं जिन्हें आप आज़मा सकते हैं, लेकिन अंत में, आपको शायद नियतात्मक असेंबली प्राप्त करने के लिए बायनेरिज़ को ठीक करना होगा।

संकलक / लिंकर द्वारा टाइमस्टैम्प जोड़ा गया

हमारे बायनेरिज़ में समय की जानकारी होने के दो मुख्य कारण हो सकते हैं जो उन्हें अचूक बनाता है:

• स्रोत में __DATE__ या __TIME__ का उपयोग करना।
• जब एक फ़ाइल स्वरूप आपको ऑब्जेक्ट फ़ाइलों में समय की जानकारी संग्रहीत करने के लिए मजबूर करता है। यह MacOS पर Windows और Mach-O पर पोर्टेबल निष्पादन योग्य प्रारूप का मामला है। लिनक्स पर, ईएलएफ फाइलें किसी टाइमस्टैम्प को एनकोड नहीं करती हैं।

आइए एक उदाहरण देखें जहां यह जानकारी MacOS पर हैलो वर्ल्ड बेस प्रोजेक्ट की स्थिर लाइब्रेरी को संकलित करने के साथ समाप्त होती है।

 . ├── CMakeLists.txt ├── hello_world.cpp ├── hello_world.hpp ├── main.cpp └── run_build.sh 

पुस्तकालय टर्मिनल में एक संदेश प्रदर्शित करता है:

 #include "hello_world.hpp" #include <iostream> void HelloWorld::PrintMessage(const std::string & message) { std::cout << message << std::endl; } 

और एप्लिकेशन "हैलो वर्ल्ड!" संदेश प्रदर्शित करने के लिए इसका उपयोग करेगा:

 #include <iostream> #include "hello_world.hpp" int main(int argc, char** argv) { HelloWorld hello; hello.PrintMessage("Hello World!"); return 0; } 

प्रोजेक्ट बनाने के लिए हम CMake का इस्तेमाल करेंगे:

 cmake_minimum_required(VERSION 3.0) project(HelloWorld) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_library(HelloLibA hello_world.cpp) add_library(HelloLibB hello_world.cpp) add_executable(helloA main.cpp) add_executable(helloB main.cpp) target_link_libraries(helloA HelloLibA) target_link_libraries(helloB HelloLibB) 

हम एक ही स्रोत कोड के साथ दो अलग-अलग पुस्तकालयों का निर्माण करेंगे, साथ ही साथ एक ही स्रोतों के साथ दो बाइनरी फाइलें भी बनाएंगे। सभी बाइनरी फ़ाइलों के चेकसम को देखने के लिए प्रोजेक्ट बनाएँ और md5sum चलाएँ:

 mkdir build && cd build cmake .. make md5sum helloA md5sum helloB md5sum CMakeFiles/HelloLibA.dir/hello_world.cpp.o md5sum CMakeFiles/HelloLibB.dir/hello_world.cpp.o md5sum libHelloLibA.a md5sum libHelloLibB.a 

हमें इस तरह एक निष्कर्ष मिलता है:

 b5dce09c593658ee348fd0f7fae22c94 helloA b5dce09c593658ee348fd0f7fae22c94 helloB 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibA.dir/hello_world.cpp.o 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibB.dir/hello_world.cpp.o adb80234a61bb66bdc5a3b4b7191eac7 libHelloLibA.a 5ac3c70d28d9fdd9c6571e077131545e libHelloLibB.a 

यह दिलचस्प है क्योंकि helloA और helloB पास एक ही चेकसम है, साथ ही Mach-O मध्यवर्ती वस्तु फ़ाइलें hello_world.cpp.o , लेकिन .a एक्सटेंशन वाली फ़ाइलों के लिए यह नहीं कहा जा सकता है। ऐसा इसलिए है क्योंकि वे एक संग्रह प्रारूप में मध्यवर्ती ऑब्जेक्ट फ़ाइलों के बारे में जानकारी संग्रहीत करते हैं। इस प्रारूप के हेडर में stat सिस्टम कॉल द्वारा st_time नामक क्षेत्र शामिल होता है। libHelloLibA.a और libHelloLibB.a जाँच करें हेडर दिखाने के लिए libHelloLibB.a का उपयोग करें:

 > otool -a libHelloLibA.a Archive : libHelloLibA.a 0100644 503/20 612 1566927276 #1/20 0100644 503/20 13036 1566927271 #1/28 > otool -a libHelloLibB.a Archive : libHelloLibB.a 0100644 503/20 612 1566927277 #1/20 0100644 503/20 13036 1566927272 #1/28 

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

इस बिंदु पर, हम चीजों को बदतर बनाने और हमारे बायनेरिज़ को भी गैर-नियतात्मक बनाने का प्रयास कर सकते हैं। __TIME__ फ़ाइल को बदलें ताकि इसमें __TIME__ मैक्रो शामिल हो:

 #include <iostream> #include "hello_world.hpp" int main(int argc, char** argv) { HelloWorld hello; hello.PrintMessage("Hello World!"); std::cout << "At time: " << __TIME__ << std::endl; return 0; } 

फ़ाइलों की जाँच फिर से करें:

 625ecc7296e15d41e292f67b57b04f15 helloA 20f92d2771a7d2f9866c002de918c4da helloB 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibA.dir/hello_world.cpp.o 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibB.dir/hello_world.cpp.o b7801c60d3bc4f83640cadc1183f43b3 libHelloLibA.a 4ef6cae3657f2a13ed77830953b0aee8 libHelloLibB.a 

हम देखते हैं कि अब हमारे पास अलग-अलग बायनेरी हैं। हम एक डिस्कोस्कोप जैसे उपकरण के साथ निष्पादन योग्य का विश्लेषण कर सकते हैं, जो दो बाइनरी फ़ाइलों के बीच अंतर दिखाता है:

 > diffoscope helloA helloB --- helloA +++ helloB ├── otool -arch x86_64 -tdvV {} │┄ Code for architecture x86_64 │ @@ -16,15 +16,15 @@ │ 00000001000018da jmp 0x1000018df │ 00000001000018df leaq -0x30(%rbp), %rdi │ 00000001000018e3 callq 0x100002d54 ## symbol stub for: __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev │ 00000001000018e8 movq 0x1721(%rip), %rdi ## literal pool symbol address: __ZNSt3__14coutE │ 00000001000018ef leaq 0x162f(%rip), %rsi ## literal pool for: "At time: " │ 00000001000018f6 callq 0x100002d8a ## symbol stub for: __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc │ 00000001000018fb movq %rax, %rdi │ -00000001000018fe leaq 0x162a(%rip), %rsi ## literal pool for: "19:40:47" │ +00000001000018fe leaq 0x162a(%rip), %rsi ## literal pool for: "19:40:48" │ 0000000100001905 callq 0x100002d8a ## symbol stub for: __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc │ 000000010000190a movq %rax, %rdi │ 000000010000190d leaq __ZNSt3__1L4endlIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_(%rip), %rsi # 

यह दिखाता है कि __TIME__ जानकारी __TIME__ बाइनरी में चिपकाया गया है, जो इसे गैर-नियतात्मक बनाता है। आइए देखें कि इससे बचने के लिए क्या किया जा सकता है।

Microsoft Visual Studio के लिए संभावित समाधान

Microsoft Visual Studio में एक लिंकर / Brepro ध्वज है जो Microsoft द्वारा प्रलेखित नहीं है। यह ध्वज पोर्टेबल निष्पादन योग्य प्रारूप से टाइमस्टैम्प को -1 पर सेट करता है, जैसा कि नीचे दिए गए चित्र में देखा गया है।



इस ध्वज को CMake के साथ सक्रिय करने के लिए, हमें .exe बनाते समय निम्नलिखित पंक्तियों को जोड़ना होगा:

 add_link_options("/Brepro") 

या इन लाइनों के लिए .lib

 set_target_properties( TARGET PROPERTIES STATIC_LIBRARY_OPTIONS "/Brepro" ) 

समस्या यह है कि यह ध्वज बायनेरिज़ को हमारे अंतिम बाइनरी .exe में फ़ाइल स्वरूप (टाइमस्टैम्प के सापेक्ष) में बनाता है, लेकिन .lib (मच-ओ ऑब्जेक्ट फ़ाइलों की तरह ही समस्या) से सभी टाइमस्टैम्प को नहीं हटाता है। जिसके बारे में हमने ऊपर बात की है)। .Lib फ़ाइलों के लिए COFF हेडर फ़ाइल से TimeDateStamp फ़ील्ड बनी रहेगी। इस जानकारी को बाइनरी .lib फ़ाइल से निकालने का एकमात्र तरीका है .Lib को किसी भी ज्ञात मान के साथ TimeDateStamp फ़ील्ड के अनुरूप बाइट्स को बदलकर ठीक करना।

GCC और CLANG के लिए संभावित समाधान

• gcc SOURCE_DATE_EPOCH पर्यावरण चर के अस्तित्व का पता लगाता है। यदि यह चर सेट किया गया है, तो इसका मान UNIX टाइमस्टैम्प को इंगित करता है जिसका उपयोग वर्तमान दिनांक और समय को __DATE__ और __TIME__ मैक्रोज़ में बदलने के लिए किया जाएगा ताकि अंतर्निहित टाइमस्टैम्प को खेलने योग्य बनाया जा सके। मान किसी ज्ञात समय स्टैम्प पर सेट किया जा सकता है, जैसे कि स्रोत फ़ाइलों या पैकेज में अंतिम परिवर्तन।
• ZERO_AR_DATE का उपयोग करता है, जो यदि सेट किया जाता है, तो संग्रह फ़ाइलों में दिए गए समय ZERO_AR_DATE रीसेट करता है, इसे 0. पर सेट करता है। ध्यान दें कि यह __DATE__ या __TIME__ ठीक नहीं करेगा। यदि हम इस मैक्रो के प्रभाव को ठीक करना चाहते हैं, तो हमें या तो बायनेरिज़ को ठीक करना होगा या सिस्टम समय को नकली करना होगा।

चलिए MacOS के लिए अपनी नमूना परियोजना जारी रखते हैं और देखते हैं कि ZERO_AR_DATE पर्यावरण ZERO_AR_DATE सेट करते समय परिणाम क्या होंगे।

 export ZERO_AR_DATE=1 

अब, यदि हम अपनी निष्पादन योग्य फ़ाइल और लाइब्रेरी संकलित करते हैं (सूत्रों में __DATE__ मैक्रो को हटाते हुए), तो हमें यह मिलता है:

 b5dce09c593658ee348fd0f7fae22c94 helloA b5dce09c593658ee348fd0f7fae22c94 helloB 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibA.dir/hello_world.cpp.o 0a4a0de3df8cc7f053f2fcb6d8b75e6d CMakeFiles/HelloLibB.dir/hello_world.cpp.o 9f9a9af4bb3e220e7a22fb58d708e1e5 libHelloLibA.a 9f9a9af4bb3e220e7a22fb58d708e1e5 libHelloLibB.a 

सभी चेकसम अब एक जैसे हैं। .a एक्सटेंशन के साथ फ़ाइल हेडर .a विश्लेषण करें।

 > otool -a libHelloLibA.a Archive : libHelloLibA.a 0100644 503/20 612 0 #1/20 0100644 503/20 13036 0 #1/28 > otool -a libHelloLibB.a Archive : libHelloLibB.a 0100644 503/20 612 0 #1/20 0100644 503/20 13036 0 #1/28 

हम देख सकते हैं कि लाइब्रेरी हेडर का timestamp फील्ड शून्य पर सेट था।

हम आसानी से लेख के पहले भाग के अंत में आ गए। सामग्री की निरंतरता को यहां पढ़ा जा सकता है ।