🕺🏾 👬 🤨 लिनक्स और macOS पर C ++ कोड का एक गर्म पुनः लोड करना: गहरा खुदाई करना ⏫ 🧛🏻 💛

* लेख के अंत में लाइब्रेरी और डेमो वीडियो से लिंक करें। यह समझने के लिए कि ये सभी लोग क्या हैं और कौन हैं, मैं पिछले लेख को पढ़ने की सलाह देता हूं।

पिछले लेख में, हमने एक दृष्टिकोण के साथ खुद को परिचित किया जो सी ++ कोड के एक गर्म पुनः लोड के लिए अनुमति देता है। इस मामले में "कोड" कार्य, डेटा और एक दूसरे के साथ उनके समन्वित कार्य हैं। फ़ंक्शंस के साथ कोई विशेष समस्याएं नहीं हैं, हम पुराने फ़ंक्शन से नए एक तक निष्पादन प्रवाह को पुनर्निर्देशित करते हैं, और सब कुछ काम करता है। समस्या डेटा (स्थिर और वैश्विक चर) के साथ उत्पन्न होती है, अर्थात् पुराने और नए कोड में उनके सिंक्रनाइज़ेशन की रणनीति के साथ। पहले कार्यान्वयन में, यह रणनीति बहुत ही अनाड़ी थी: हम पुराने कोड से सभी स्थिर चर के मूल्यों को नए में कॉपी करते हैं, ताकि नए कोड, नए चर का जिक्र करते हुए पुराने कोड से मानों के साथ काम करें। बेशक, यह गलत है, और आज हम एक साथ कई छोटी लेकिन दिलचस्प समस्याओं को हल करके इस दोष को ठीक करने की कोशिश करेंगे।

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

दिल

आइए कल्पना करें कि हमारे पास एक वर्ग है (सिंथेटिक उदाहरण, कृपया उनमें अर्थ न देखें, केवल कोड महत्वपूर्ण है):

// Entity.hpp class Entity { public: Entity(const std::string& description); ~Entity(); void printDescription(); static int getLivingEntitiesCount(); private: static int m_livingEntitiesCount; std::string m_description; }; // Entity.cpp int Entity::m_livingEntitiesCount = 0; Entity::Entity(const std::string& description) : m_description(description) { m_livingEntitiesCount++; } Entity::~Entity() { m_livingEntitiesCount--; } int Entity::getLivingEntitiesCount() { return m_livingEntitiesCount; } void Entity::printDesctiption() { std::cout << m_description << std::endl; }

कुछ खास नहीं बल्कि एक स्टैटिक वेरिएबल। अब कल्पना करें कि हम printDescription() विधि को बदलना चाहते हैं:

 void Entity::printDescription() { std::cout << "DESCRIPTION: " << m_description << std::endl; }

कोड रीलोड के बाद क्या होता है? Entity वर्ग के तरीकों के अलावा, स्थिर चर m_livingEntitiesCount भी नए कोड के साथ पुस्तकालय में जाता है। कुछ भी बुरा नहीं होगा यदि हम इस चर के मान को पुराने कोड से नए में कॉपी करते हैं और नए चर का उपयोग करना जारी रखते हैं, पुराने को भूल जाते हैं, क्योंकि इस चर का उपयोग करने वाले सभी तरीके नए कोड के साथ लाइब्रेरी में हैं।

C ++ बहुत लचीला और समृद्ध है। और जब फाउल-स्मेलिंग कोड पर c ++ सीमाओं में कुछ समस्याओं को हल करने की लालित्य, मुझे यह भाषा पसंद है। उदाहरण के लिए, कल्पना करें कि आपकी परियोजना rtti का उपयोग नहीं करती है। इसी समय, आपको कुछ प्रकार के सुरक्षित इंटरफ़ेस के साथ Any वर्ग के कार्यान्वयन की आवश्यकता है:

 class Any { public: template <typename T> explicit Any(T&& value) { ... } template <typename T> bool is() const { ... } template <typename T> T& as() { ... } };

हम इस वर्ग के कार्यान्वयन के विवरण में नहीं जाएंगे। हमारे लिए जो महत्वपूर्ण है वह यह है कि कार्यान्वयन के लिए हमें किसी प्रकार के संकलित मानचित्रण (संकलित-समय इकाई) के लिए किसी चर के मान में किसी प्रकार के तंत्र की आवश्यकता होती है, उदाहरण के लिए, uint64_t (रनटाइम इकाई), यानी "गणना" प्रकार। Rtti का उपयोग करते समय, type_info और, हमारे लिए अधिक उपयुक्त, type_index जैसी चीजें हमारे लिए उपलब्ध हैं। लेकिन हमारे पास आरटीआई नहीं है। इस मामले में, काफी सामान्य हैक (या सुरुचिपूर्ण समाधान?) क्या यह फ़ंक्शन है:

 template <typename T> uint64_t typeId() { static char someVar; return reinterpret_cast<uint64_t>(&someVar); }

तब Any वर्ग का कार्यान्वयन कुछ इस तरह दिखाई देगा:

 class Any { public: template <typename T> explicit Any(T&& value) : m_typeId(typeId<std::decay<T>::type>()) // copy or move value somewhere {} template <typename T> bool is() const { return m_typeId == typeId<std::decay<T>::type>(); } template <typename T> T& as() { ... } private: uint64_t m_typeId = 0; };

प्रत्येक प्रकार के लिए, फ़ंक्शन को क्रमशः 1 बार ठीक किया जाएगा, क्रमशः फ़ंक्शन के प्रत्येक संस्करण का अपना स्थिर चर होगा, जाहिर है कि इसका अपना अनूठा पता होगा। जब हम इस फ़ंक्शन का उपयोग करके कोड को पुनः लोड करते हैं तो क्या होता है? फ़ंक्शन के पुराने संस्करण की कॉल को नए पर पुनर्निर्देशित किया जाएगा। नए का अपना स्टैटिक वेरिएबल पहले से ही इनिशियलाइज़ होगा (हमने वैल्यू और गार्ड वेरिएबल को कॉपी किया)। लेकिन हम अर्थ में रुचि नहीं रखते हैं, हम केवल पते का उपयोग करते हैं। और नए चर का पता अलग होगा। इस प्रकार, डेटा असंगत हो गया: Any वर्ग के पहले से ही निर्मित उदाहरणों में, पुराने स्थिर चर का पता संग्रहीत किया जाएगा, और is() विधि नए के पते के साथ इसकी तुलना करेगी और "यह अब Any समान नहीं Any " ©।

योजना

इस समस्या को हल करने के लिए, आपको केवल कॉपी करने की तुलना में कुछ समझदारी की आवश्यकता है। Google पर कुछ शामें बिताने के बाद, प्रलेखन, स्रोत कोड और सिस्टम एपी पढ़ने के बाद, निम्नलिखित योजना मेरे दिमाग में बनी:

नया कोड बनाने के बाद, हम रिलोकेशन से गुजरते हैं।
इन स्थानांतरणों से हमें कोड में सभी स्थान मिलते हैं जो स्थैतिक (और कभी-कभी वैश्विक) चर का उपयोग करते हैं।
चरों के नए संस्करणों के पते के बजाय, हम पुराने संस्करणों के पते को स्थानांतरण के स्थान पर प्रतिस्थापित करते हैं।

इस मामले में, नए डेटा के लिए कोई लिंक नहीं होगा, पूरा एप्लिकेशन पुराने संस्करणों के पते के साथ काम करना जारी रखेगा। वह काम करना चाहिए। यह काम करने में विफल नहीं हो सकता।

स्थान परिवर्तन

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

स्थानांतरण में जानकारी शामिल है:

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

विभिन्न ओएस में, रिलोकेशन को अलग-अलग रूप से दर्शाया जाता है, लेकिन अंत में वे सभी एक ही सिद्धांत पर काम करते हैं। उदाहरण के लिए, एल्फ (लिनक्स) में, स्थानांतरण विशेष .rela वर्गों (32-बिट संस्करण में यह .rel ) में स्थित .rel , जो उस पते के साथ अनुभाग को संदर्भित करता है जिसे ठीक करने की आवश्यकता होती है (उदाहरण के लिए, .rela.text - वह खंड जिसमें स्थानांतरण स्थित हैं। .text अनुभाग पर लागू होता है), और प्रत्येक प्रविष्टि उस प्रतीक के बारे में जानकारी संग्रहीत करती है जिसका पता आप स्थानांतरण स्थल पर लगाना चाहते हैं। मच-ओ (macOS) में, विपरीत स्थिति है; रिलोकेशन्स के लिए कोई अलग सेक्शन नहीं है; इसके बजाय, प्रत्येक सेक्शन में रिलोकेशन्स की तालिका के लिए एक पॉइंटर होता है जिसे इस सेक्शन में लागू किया जाना चाहिए, और इस तालिका के प्रत्येक रिकॉर्ड में एक रिलेशनल सिंबल का संदर्भ होता है।
उदाहरण के लिए, ऐसे कोड के लिए ( -fPIC विकल्प के साथ):

 int globalVariable = 10; int veryUsefulFunction() { static int functionLocalVariable = 0; functionLocalVariable++; return globalVariable + functionLocalVariable; }

कंपाइलर लिनक्स पर रिलोकेशन के साथ इस तरह का एक सेक्शन बनाएगा:

 Relocation section '.rela.text' at offset 0x1a0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000007 0000000600000009 R_X86_64_GOTPCREL 0000000000000000 globalVariable - 4 000000000000000d 0000000400000002 R_X86_64_PC32 0000000000000000 .bss - 4 0000000000000016 0000000400000002 R_X86_64_PC32 0000000000000000 .bss - 4 000000000000001e 0000000400000002 R_X86_64_PC32 0000000000000000 .bss - 4

और इस तरह के एक स्थानांतरण तालिका macOS पर:

 RELOCATION RECORDS FOR [__text]: 000000000000001b X86_64_RELOC_SIGNED __ZZ18veryUsefulFunctionvE21functionLocalVariable 0000000000000015 X86_64_RELOC_SIGNED _globalVariable 000000000000000f X86_64_RELOC_SIGNED __ZZ18veryUsefulFunctionvE21functionLocalVariable 0000000000000006 X86_64_RELOC_SIGNED __ZZ18veryUsefulFunctionvE21functionLocalVariable

और यहाँ (लिनक्स पर veryUsefulFunction() फ़ंक्शन बहुत veryUsefulFunction() :

 0000000000000000 <_Z18veryUsefulFunctionv>: 0: 55 push rbp 1: 48 89 e5 mov rbp,rsp 4: 48 8b 05 00 00 00 00 mov rax,QWORD PTR [rip+0x0] b: 8b 0d 00 00 00 00 mov ecx,DWORD PTR [rip+0x0] 11: 83 c1 01 add ecx,0x1 14: 89 0d 00 00 00 00 mov DWORD PTR [rip+0x0],ecx 1a: 8b 08 mov ecx,DWORD PTR [rax] 1c: 03 0d 00 00 00 00 add ecx,DWORD PTR [rip+0x0] 22: 89 c8 mov eax,ecx 24: 5d pop rbp 25: c3 ret

और इसलिए वस्तु को गतिशील पुस्तकालय से जोड़ने के बाद:

 00000000000010e0 <_Z18veryUsefulFunctionv>: 10e0: 55 push rbp 10e1: 48 89 e5 mov rbp,rsp 10e4: 48 8b 05 05 21 00 00 mov rax,QWORD PTR [rip+0x2105] 10eb: 8b 0d 13 2f 00 00 mov ecx,DWORD PTR [rip+0x2f13] 10f1: 83 c1 01 add ecx,0x1 10f4: 89 0d 0a 2f 00 00 mov DWORD PTR [rip+0x2f0a],ecx 10fa: 8b 08 mov ecx,DWORD PTR [rax] 10fc: 03 0d 02 2f 00 00 add ecx,DWORD PTR [rip+0x2f02] 1102: 89 c8 mov eax,ecx 1104: 5d pop rbp 1105: c3 ret

4 जगहें हैं जिनमें 4 बाइट्स असली चर के पते के लिए आरक्षित हैं।

विभिन्न प्रणालियों पर, संभावित स्थानांतरण का सेट आपका अपना है। लिनक्स पर x86-64 पर, 40 से अधिक प्रकार के स्थानांतरण । वहाँ x86-64 पर macOS पर उनमें से केवल 9 हैं। सभी प्रकार के स्थानांतरणों को सशर्त रूप से 2 समूहों में विभाजित किया जा सकता है:

लिंक-टाइम रिलोकेशन - ऑब्जेक्ट फाइल को एग्जीक्यूटेबल फाइल या डायनेमिक लाइब्रेरी से लिंक करने की प्रक्रिया में इस्तेमाल होने वाले रिलोकेशन
लोड-टाइम रिलोकेशन - डायनेमिक लाइब्रेरी को प्रोसेस मेमोरी में लोड करने के समय रिलोकेशन लागू किया जाता है

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

MacOS और इसके डायनेमिक लिंकर से जुड़ा एक सूक्ष्म बिंदु है। MacOS तथाकथित दो-स्तरीय नामस्थान तंत्र को लागू करता है। यदि यह कठोर है, तो डायनेमिक लाइब्रेरी लोड करते समय, लिंकर पहले इस लाइब्रेरी में वर्णों की खोज करेगा, और यदि यह नहीं मिला, तो यह दूसरों में खोज करेगा। यह प्रदर्शन उद्देश्यों के लिए किया जाता है, ताकि स्थानांतरण जल्दी से हल हो जाएं, जो सामान्य रूप से तार्किक है। लेकिन इससे वैश्विक चरों के बारे में हमारा प्रवाह टूट जाता है। सौभाग्य से, -flat_namespace पर ld का एक विशेष ध्वज है - -flat_namespace , और यदि आप इस ध्वज के साथ एक लाइब्रेरी का निर्माण करते हैं, तो वर्ण खोज एल्गोरिथ्म लिनक्स में इसके समान होगा।

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

लिनक्स पर .rela.text सेक्शन और __text पर __text सेक्शन द्वारा संदर्भित रिलोकेशन, और
जो लिनक्स और __data , __bss और मैक पर __common , और
स्थानांतरण प्रकार R_X86_64_PC32 और R_X86_64_PC64 लिनक्स पर और X86_64_RELOC_SIGNED , X86_64_RELOC_SIGNED_1 , X86_64_RELOC_SIGNED_2 और X86_64_RELOC_SIGNED_4 ।

सूक्ष्म बिंदु __common अनुभाग के साथ जुड़ा हुआ है। लिनक्स में भी एक समान *COM* सेक्शन है। वैश्विक चर इस खंड में आ सकते हैं। लेकिन, जब मैंने लिनक्स पर कोड स्निपेट्स का एक समूह परीक्षण और संकलित किया, तो नियमित रूप से वैश्विक चर की तरह, *COM* अनुभाग से चरित्र स्थानांतरण हमेशा गतिशील थे। उसी समय, macOS पर ऐसे वर्ण कभी-कभी लिंक करने के दौरान स्थानांतरित हो जाते थे यदि फ़ंक्शन और वर्ण एक ही फ़ाइल में हों। इसलिए, macOS पर वर्णों और रिलोकेशन को पढ़ते समय इस खंड पर विचार करना समझ में आता है।

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

 resultAddr = newVarAddr + addend - relocAddr

उसी समय, हम चर के दोनों संस्करणों के पते जानते हैं - पुराने, पहले से ही आवेदन में रहने वाले, और नए। सूत्र द्वारा इसे बदलना हमारे लिए शेष है:

 resultAddr = resultAddr - newVarAddr + oldVarAddr

और इसे स्थानांतरण पते पर लिखें। उसके बाद, नए कोड में सभी फ़ंक्शन चर के मौजूदा संस्करणों का उपयोग करेंगे, और नए चर बस झूठ और कुछ नहीं करेंगे। आपको क्या चाहिए! लेकिन एक सूक्ष्म बिंदु है।

नए कोड के साथ लाइब्रेरी को डाउनलोड करना

जब सिस्टम डायनामिक लाइब्रेरी को प्रोसेस मेमोरी में लोड करता है, तो इसे वर्चुअल एड्रेस स्पेस में कहीं भी रखने के लिए स्वतंत्र है। मेरे उबंटू 18.04 पर, आवेदन 0x00400000 में लोड किया 0x00400000 , और 0x7fd3829bd000 क्षेत्र के पते पर ld-2.27.so ठीक बाद हमारी डायनेमिक लाइब्रेरी। कार्यक्रम और पुस्तकालय के डाउनलोड पतों के बीच की दूरी उस संख्या से बहुत बड़ी है जो हस्ताक्षरित 32-बिट पूर्णांक में फिट होगी। और लिंक-टाइम रिलोकेशन में, लक्ष्य पात्रों के पते के लिए केवल 4 बाइट्स आरक्षित हैं।

संकलक और -mcmodel=large लिए दस्तावेज़ धूम्रपान करने के बाद, मैंने -mcmodel=large विकल्प की कोशिश करने का फैसला किया। यह संकलक को वर्णों के बीच की दूरी के बारे में किसी भी धारणा के बिना कोड उत्पन्न करने के लिए मजबूर करता है, जिससे सभी पते 64-बिट के मान लिए जाते हैं। लेकिन यह विकल्प PIC के अनुकूल नहीं है, जैसे कि -mcmodel=large -fPIC साथ -mcmodel=large उपयोग नहीं किया जा सकता है, कम से कम -fPIC पर। मुझे अभी भी समझ में नहीं आ रहा है कि समस्या क्या है, शायद macOS पर इस स्थिति के लिए कोई उपयुक्त स्थानांतरण नहीं हैं।

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

सौभाग्य से, प्रलेखन को यह बताने के लिए आवश्यक विकल्प मिले कि हमारे गतिशील पुस्तकालय को कहां डाउनलोड करें:

Apple ld: -image_base 0xADDRESS
LLVM lld: --image-base=0xADDRESS
GNU ld: -Ttext-segment=0xADDRESS

डायनेमिक लाइब्रेरी को लिंक करने के समय ये विकल्प लिंकर को दिए जाने चाहिए। 2 कठिनाइयाँ हैं।
पहला GNU ld से संबंधित है। इन विकल्पों के काम करने के लिए, आपको निम्न करने की आवश्यकता है:

पुस्तकालय को लोड करने के समय, जिस क्षेत्र में हम इसे लोड करना चाहते हैं, वह मुक्त था
विकल्प में निर्दिष्ट पता पृष्ठ आकार का एक बहु होना चाहिए (x86-64 लिनक्स और 0x1000 यह 0x1000 )
कम से कम लिनक्स पर, विकल्प में निर्दिष्ट पता PT_LOAD खंड के संरेखण का एक PT_LOAD होना चाहिए

यही है, यदि लिंकर ने संरेखण को 0x10000000 सेट किया है, तो यह पुस्तकालय 0x10001000 पते पर लोड नहीं किया जा सकता है, भले ही पता पृष्ठ के आकार से जुड़ा हो। यदि इनमें से कोई एक शर्त पूरी नहीं होती है, तो पुस्तकालय "हमेशा की तरह" लोड होगा। मेरे पास अपने सिस्टम पर GNU ld 2.30 है, और, LLVM lld के विपरीत, डिफ़ॉल्ट रूप से यह PT_LOAD खंड के संरेखण को PT_LOAD सेट करता है, जो चित्र से बहुत बाहर है। इसके चारों ओर पाने के लिए -Ttext-segment=... विकल्प के अलावा, -Ttext-segment=... -z max-page-size=0x1000 । मैंने एक दिन बिताया जब तक मुझे एहसास नहीं हुआ कि लाइब्रेरी को वहां लोड नहीं किया जा रहा है जहां मुझे आवश्यकता है।

दूसरी कठिनाई - डाउनलोड पता पुस्तकालय के लिंकिंग चरण में जाना जाना चाहिए। इसे व्यवस्थित करना बहुत मुश्किल नहीं है। लिनक्स में, यह छद्म फाइल /proc/<pid>/maps को पार्स करने के लिए पर्याप्त है, प्रोग्राम में निकटतम अप्रकाशित टुकड़ा ढूंढें, जिसमें लाइब्रेरी फिट होगी, और लिंक करते समय इस टुकड़े की शुरुआत के पते का उपयोग करें। भविष्य की लाइब्रेरी के आकार का अनुमान मोटे तौर पर ऑब्जेक्ट फ़ाइलों के आकार को देखकर, या उन्हें पार्स करके और सभी वर्गों के आकार की गणना करके लगाया जा सकता है। अंत में, हमें एक सटीक संख्या की आवश्यकता नहीं है, लेकिन एक मार्जिन के साथ अनुमानित आकार।

MacOS में /proc/* ; इसके बजाय, यह सुझाव दिया जाता है कि आप vmmap उपयोगिता का उपयोग करें। vmmap -interleaved <pid> कमांड से आउटपुट में समान जानकारी होती है जैसे कि proc/<pid>/maps । लेकिन यहां एक और मुश्किल खड़ी हो जाती है। यदि कोई एप्लिकेशन एक बच्चा प्रक्रिया बनाता है जो इस कमांड को निष्पादित करता है, और वर्तमान प्रक्रिया के पहचानकर्ता को <pid> रूप में निर्दिष्ट किया जाता है, तो प्रोग्राम तंग हो जाएगा। जैसा कि मैं इसे समझता हूं, vmmap अपनी मेमोरी मैपिंग को पढ़ने के लिए प्रक्रिया को रोक देता है, और जाहिर है, अगर यह कॉलिंग प्रक्रिया है, तो यह गलत है। इस मामले में, आपको अतिरिक्त फ़्लैग- -forkCorpse निर्दिष्ट करने की आवश्यकता है ताकि vmmap हमारी प्रक्रिया से एक खाली बच्चे की प्रक्रिया बना सके, उसमें से मैपिंग को हटा दें और उसे मार दें, जिससे प्रोग्राम में व्यवधान न हो।

यह मूल रूप से हम सभी को पता होना चाहिए।

यह सब एक साथ रखना

इन संशोधनों के साथ, अंतिम कोड पुनः लोड एल्गोरिथ्म इस तरह दिखता है:

नए कोड को ऑब्जेक्ट फ़ाइलों में संकलित करें
ऑब्जेक्ट फ़ाइलों के लिए, हम भविष्य के पुस्तकालय के आकार का अनुमान लगाते हैं
पढ़ना पुनर्वास ऑब्जेक्ट फ़ाइलें
हम एप्लिकेशन के बगल में वर्चुअल मेमोरी के एक निशुल्क टुकड़े की तलाश कर रहे हैं
हम आवश्यक विकल्पों के साथ एक गतिशील पुस्तकालय का निर्माण करते हैं, dlopen माध्यम से dlopen
लिंक-टाइम रिलोकेशन के अनुसार पैच कोड
पैच समारोह
स्थिर चर की प्रतिलिपि बनाएँ जो चरण 6 में भाग नहीं लेते थे

केवल स्टैटिक वैरिएबल के गार्ड चर चरण 8 में आते हैं, इसलिए उन्हें सुरक्षित रूप से कॉपी किया जा सकता है (जिससे स्वयं स्टैटिक वैरिएबल के "इनिशियलाइज़ेशन" को संरक्षित किया जा सकता है)।

निष्कर्ष

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

पूर्णता के लिए, कार्यान्वयन में 3 और वज़नदार टुकड़े गायब हैं:

अब नए कोड वाली लाइब्रेरी को प्रोग्राम के बगल में मेमोरी में लोड किया जाता है, हालांकि एक अन्य डायनेमिक लाइब्रेरी से कोड जो अभी तक लोड किया गया है, उसमें मिल सकता है। ठीक करने के लिए, आपको अनुवाद इकाइयों के स्वामित्व को एक या दूसरे पुस्तकालय और कार्यक्रम पर ट्रैक करना होगा, और यदि आवश्यक हो तो नए कोड के साथ पुस्तकालय को विभाजित करना होगा।
बहु-थ्रेडेड अनुप्रयोग में रीलोडिंग कोड अभी भी अविश्वसनीय है (निश्चितता के साथ आप केवल कोड को फिर से लोड कर सकते हैं जो रन थ्रू लाइब्रेरी के रूप में उसी थ्रेड में चलता है)। निर्धारण के लिए, कार्यान्वयन के हिस्से को एक अलग कार्यक्रम में स्थानांतरित करना आवश्यक है, और पैचिंग से पहले इस कार्यक्रम को सभी थ्रेड्स, पैच के साथ प्रक्रिया को रोकना होगा और इसे काम पर वापस करना होगा। मुझे नहीं पता कि बाहरी कार्यक्रम के बिना यह कैसे करना है।
कोड पुनः लोड होने के बाद आकस्मिक आवेदन दुर्घटना की रोकथाम। कोड को ठीक करने के बाद, आप गलती से नए कोड में अमान्य पॉइंटर को रोक सकते हैं, जिसके बाद आपको एप्लिकेशन को पुनरारंभ करना होगा। कुछ भी गलत नहीं है, लेकिन फिर भी। काले जादू की तरह लगता है, मैं अभी भी विचार में हूँ।

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

डेमो

चूंकि कार्यान्वयन मक्खी पर नई प्रसारण इकाइयों को जोड़ने की अनुमति देता है, मैंने एक छोटा वीडियो रिकॉर्ड करने का फैसला किया, जिसमें मैं स्क्रैच से ब्रह्मांड के विस्तार और शूटिंग वर्ग क्षुद्रग्रहों की जुताई के बारे में एक सरल सरल खेल लिखता हूं। मैंने "ऑल इन वन फाइल" की शैली में लिखने की कोशिश नहीं की, लेकिन यदि संभव हो तो, अलमारियों पर सब कुछ व्यवस्थित करना, जिससे कई छोटी फाइलें पैदा होती हैं (इसलिए, इतना स्क्रिबल बाहर आया)। बेशक, रूपरेखा का उपयोग ड्राइंग, इनपुट, विंडो और अन्य चीजों के लिए किया जाता है, लेकिन खेल का कोड खरोंच से ही लिखा गया था।
मुख्य विशेषता - मैंने केवल 3 बार आवेदन चलाया: बहुत शुरुआत में, जब इसमें केवल एक खाली दृश्य था, और मेरी लापरवाही के कारण गिरने के बाद 2 बार। पूरा खेल कोड लिखने की प्रक्रिया में बढ़ा-चढ़ाकर पेश किया गया। वास्तविक समय - लगभग 40 मिनट। सामान्य तौर पर, आपका स्वागत है।

हमेशा की तरह, मुझे किसी भी आलोचना में खुशी होगी, धन्यवाद!

कार्यान्वयन के लिए लिंक

लिनक्स और macOS पर C ++ कोड का एक गर्म पुनः लोड करना: गहरा खुदाई करना