लिनक्स पर C ++ कोड के एक गर्म पुनः लोड को लागू करना

* लेख के अंत में पुस्तकालय से लिंक करें। यह लेख स्वयं पुस्तकालय में लागू तंत्रों को मध्यम विस्तार के साथ रेखांकित करता है। MacOS के लिए कार्यान्वयन अभी तक समाप्त नहीं हुआ है, लेकिन यह लिनक्स के लिए कार्यान्वयन से बहुत अलग नहीं है। यह मुख्य रूप से लिनक्स के लिए एक कार्यान्वयन है।

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

मुझे तुरंत यह कहना होगा कि मुझे केवल उस विकल्प में दिलचस्पी थी जिसमें मुझे मौजूदा प्रोजेक्ट कोड को बदलना नहीं होगा (उदाहरण के लिए, RCCPP या cr के मामले में, जहाँ सभी संभावित पुनः लोड कोड एक अलग गतिशील रूप से भरी हुई लाइब्रेरी में होना चाहिए)।

"यह कैसे?" - मैंने सोचा, और धूप जलाना शुरू कर दिया।

क्यों?

मैं मुख्य रूप से gamedev करता हूं। अपने काम के अधिकांश समय मैं किसी भी दृश्य के खेल तर्क और लेआउट लिखने पर खर्च करता हूं। मैं भी सहायक उपयोगिताओं के लिए imgui का उपयोग करें। कोड के साथ काम करने का मेरा चक्र, जैसा कि आपने शायद अनुमान लगाया है, लिखें -> संकलन -> भागो -> दोहराएं। सब कुछ बहुत जल्दी होता है (वृद्धिशील निर्माण, सभी प्रकार के ccache, आदि)। यहां समस्या यह है कि इस चक्र को अक्सर पर्याप्त रूप से दोहराया जाना है। उदाहरण के लिए, मैं एक नया गेम मैकेनिक्स लिख रहा हूं, इसे "जंप" होने दें, एक वैध, नियंत्रित जंप:

1. एक ड्राफ्ट कार्यान्वयन पर आधारित गति, इकट्ठा, लॉन्च। मैंने देखा कि मैं गलती से प्रत्येक फ्रेम में एक नाड़ी लगाता हूं, और एक बार नहीं।

2. फिक्स्ड, असेंबल, लॉन्च, अब सामान्य। लेकिन आवेग का पूर्ण मूल्य अधिक लेना आवश्यक होगा।

3. फिक्स्ड, असेंबल, लॉन्च, वर्किंग। लेकिन किसी तरह यह गलत लगता है। करने के लिए शक्ति के आधार पर प्रयास करना आवश्यक है।

4. ताकत, इकट्ठे, लॉन्च, कार्यों के आधार पर एक मसौदा कार्यान्वयन लिखा। केवल कूद के समय तात्कालिक गति को बदलना आवश्यक होगा।
...

10. फिक्स्ड, असेंबल, लॉन्च, वर्किंग। लेकिन फिर भी ऐसा नहीं है। शायद gravityScale में परिवर्तन के आधार पर कार्यान्वयन की कोशिश करने की आवश्यकता है।
...

20. शानदार, यह सुपर लग रहा है! अब हम gamediz के लिए संपादक में सभी पैरामीटर निकालते हैं, परीक्षण करते हैं और भरते हैं।
...

30. कूदने के लिए तैयार है।

और प्रत्येक पुनरावृत्ति पर, आपको कोड एकत्र करने की आवश्यकता है और लॉन्च किए गए एप्लिकेशन में उस स्थान पर पहुंचें जहां मैं कूद सकता हूं। यह आमतौर पर कम से कम 10 सेकंड लेता है। और अगर मैं केवल एक खुले क्षेत्र में कूद सकता हूं, जिसे अभी भी पहुंचने की आवश्यकता है? और अगर मुझे एन इकाइयों की ऊंचाई के साथ ब्लॉकों पर कूदने में सक्षम होने की आवश्यकता है? यहां मुझे पहले से ही एक परीक्षण दृश्य एकत्र करने की आवश्यकता है, जिसे डिबग करने की भी आवश्यकता है, और जिसे समय बिताने की भी आवश्यकता है। यह ऐसे पुनरावृत्तियों के लिए है कि कोड का एक गर्म पुनः लोड आदर्श होगा। बेशक, यह एक रामबाण नहीं है, यह सब कुछ के लिए उपयुक्त नहीं है, और कभी-कभी रिबूट करने के बाद आपको खेल की दुनिया का हिस्सा फिर से बनाने की आवश्यकता होती है, और इसे ध्यान में रखा जाना चाहिए। लेकिन कई चीजों में, यह उपयोगी हो सकता है और ध्यान और बहुत समय बचा सकता है।

आवश्यकताओं और समस्या का बयान

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

यह आवश्यकताओं का न्यूनतम सेट है जिसे एक कार्यान्वयन को पूरा करना चाहिए। आगे देखते हुए, मैं संक्षेप में बताऊंगा कि इसके अतिरिक्त क्या लागू किया गया था:

• स्थैतिक चर के मानों को नए कोड में स्थानांतरित करना (देखें कि "यह महत्वपूर्ण क्यों है, यह जानने के लिए" स्थैतिक चर को स्थानांतरित करना ")
• निर्भरता के आधार पर रिलोड करना (हेडर बदला -> पुनर्निर्माण आधा प्रोजेक्ट सभी आश्रित फाइलें)
• गतिशील पुस्तकालयों से कोड पुनः लोड करना

कार्यान्वयन

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

उच्च स्तर पर, तंत्र इस तरह दिखता है:

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

चलो सबसे दिलचस्प के साथ शुरू करते हैं - फ़ंक्शन पुनः लोड तंत्र।

पुनः लोड करने का कार्य

यहां (या लगभग) रनटाइम में कार्यों को बदलने के लिए 3 अधिक या कम लोकप्रिय तरीके हैं:

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

पहले 2 विकल्प, स्पष्ट रूप से, उपयुक्त नहीं हैं, क्योंकि वे केवल निर्यात किए गए कार्यों के साथ काम करते हैं, और हम अपने आवेदन के सभी कार्यों को किसी भी विशेषता के साथ चिह्नित नहीं करना चाहते हैं। इसलिए, फंक्शन हुकिंग हमारा विकल्प है!

संक्षेप में, हुकिंग इस तरह काम करता है:

• फ़ंक्शन का पता मिला है
• फ़ंक्शन के पहले कुछ बाइट्स किसी अन्य फ़ंक्शन के शरीर में बिना शर्त संक्रमण द्वारा ओवरराइट किए जाते हैं
• ...
• लाभ!
  Msvc में इसके लिए 2 झंडे हैं - /hotpatch और /FUNCTIONPADMIN । प्रत्येक फ़ंक्शन की शुरुआत में पहला 2 बाइट्स लिखता है, जो कि "शॉर्ट जंप" के साथ उनके बाद के पुनर्लेखन के लिए कुछ भी नहीं करता है। दूसरा आपको प्रत्येक फ़ंक्शन के शरीर के सामने खाली स्थान को "लंबी छलांग" के लिए इच्छित स्थान पर "लंबी छलांग" के रूप में छोड़ने की अनुमति देता है, इसलिए 2 जंप में आप पुराने फ़ंक्शन से नए पर स्विच कर सकते हैं। आप इस बारे में अधिक पढ़ सकते हैं कि यह कैसे विंडोज़ और msvc में लागू किया जाता है, उदाहरण के लिए, यहाँ ।

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

एक सूक्ष्म बिंदु है। 32-बिट सिस्टम पर, किसी भी स्थान पर "कूद" करने के लिए 5 बाइट्स पर्याप्त हैं। 64-बिट सिस्टम पर, यदि हम रजिस्टरों को खराब नहीं करना चाहते हैं, तो हमें 14 बाइट्स की आवश्यकता है। लब्बोलुआब यह है कि मशीन कोड के पैमाने में 14 बाइट्स काफी हैं, और यदि कोड में किसी खाली शरीर के साथ कोई स्टब फ़ंक्शन है, तो यह सबसे अधिक लंबाई में 14 बाइट्स से कम होगा। मुझे पूरी सच्चाई का पता नहीं है, लेकिन मैंने कोड के बारे में सोचने, लिखने और डिबग करने के दौरान डिसैम्बलेर के पीछे कुछ समय बिताया, और मैंने देखा कि सभी फ़ंक्शंस 16-बाइट सीमा (बिना ऑप्टिमाइज़ेशन के डिबग बिल्ड, ऑल्टर्ड कोड के लिए निश्चित नहीं हैं) पर संरेखित हैं। और इसका मतलब है कि किसी भी दो कार्यों की शुरुआत के बीच कम से कम 16 बाइट्स होंगे, जो हमारे लिए उन्हें "जाम" करने के लिए पर्याप्त है। सतही गुगली का नेतृत्व किया, हालांकि, मुझे यकीन है कि पता नहीं था, मैं सिर्फ भाग्यशाली था, या आज सभी संकलक ऐसा करते हैं। किसी भी मामले में, अगर संदेह है, तो बस स्टब फ़ंक्शन की शुरुआत में कुछ चर घोषित करें ताकि यह पर्याप्त रूप से बड़ा हो जाए।

इसलिए, हमारे पास पहला अनाज है - पुराने संस्करण से नए पर पुनर्निर्देशन के लिए एक तंत्र।

एक कॉपी किए गए प्रोग्राम में कार्यों की खोज करें

अब हमें अपने कार्यक्रम या मनमाने ढंग से गतिशील पुस्तकालय से सभी के पते (न केवल निर्यात किए गए) कार्यों को प्राप्त करने की आवश्यकता है। यह काफी सरलता से सिस्टम एपीआई का उपयोग करके किया जा सकता है यदि वर्ण आपके आवेदन से कटे हुए नहीं हैं। लिनक्स पर, ये elf.h और link.h से elf.h , loader.h , loader.h और nlist.h ।

• dl_iterate_phdr का उपयोग dl_iterate_phdr हम सभी भरी हुई लाइब्रेरियों से dl_iterate_phdr हैं और, वास्तव में, कार्यक्रम
• वह पता लगाएं जहां पुस्तकालय लोड है
• .symtab सेक्शन से .symtab वर्णों के बारे में सभी जानकारी मिलती है, अर्थात् नाम, प्रकार, उस अनुभाग का सूचकांक जिसमें वह निहित है, आकार, और आभासी पते और लाइब्रेरी लोड पते के आधार पर इसके "वास्तविक" पते की गणना भी करते हैं।

एक-एक सूक्ष्मता है। योगिनी फ़ाइल डाउनलोड करते समय, सिस्टम .symtab सेक्शन (यदि यह गलत है तो सही है) लोड नहीं करता है, और .dynsym सेक्शन हमें सूट नहीं करता है, क्योंकि हम इसमें से दृश्यता STV_INTERNAL और STV_HIDDEN वर्ण नहीं निकाल सकते हैं। सीधे शब्दों में कहें, तो हम ऐसे कार्य नहीं देखेंगे:

 // some_file.cpp namespace { int someUsefulFunction(int value) // <----- { return value * 2; } } 

और इस तरह के चर:

 // some_file.cpp void someDefaultFunction() { static int someVariable = 0; // <----- ... } 

इस प्रकार, अनुच्छेद 3 में, हम उस प्रोग्राम के साथ काम नहीं कर रहे हैं जो dl_iterate_phdr ने dl_iterate_phdr दिया, लेकिन उस फ़ाइल के साथ जिसे हमने डिस्क से डाउनलोड किया और कुछ योगिनी पार्सर (या नंगे एपी) द्वारा पार्स किया। इसलिए हम कुछ भी याद नहीं करते हैं। MacOS पर, प्रक्रिया समान है, केवल सिस्टम एपीआई से कार्यों के नाम अलग हैं।

उसके बाद, हम सभी वर्णों को फ़िल्टर करते हैं और केवल सहेजते हैं:

• पुनः लोड किए जाने वाले STT_FUNC अनुभाग में स्थित STT_FUNC प्रकार के वर्ण हैं, जो आकार में गैर-शून्य हैं। इस तरह का फ़िल्टर केवल वही कार्य करता है जिसका कोड वास्तव में इस प्रोग्राम या लाइब्रेरी में निहित है
• स्थैतिक चर जिनके मूल्य आप स्थानांतरित करना चाहते हैं वे .bss खंड में स्थित STT_OBJECT के प्रकार हैं

प्रसारण इकाइयाँ

कोड को फिर से लोड करने के लिए, हमें यह जानना होगा कि स्रोत कोड फाइलें कहां से प्राप्त करें और उन्हें कैसे संकलित करें।

पहले कार्यान्वयन में, मैंने .debug_info अनुभाग से यह जानकारी पढ़ी, जिसमें DWARF प्रारूप में डीबगिंग जानकारी शामिल है। इस ET के लिए एक संकलन लाइन प्राप्त करने के लिए DWARF के भीतर प्रत्येक संकलन इकाई (ET) के लिए, आपको संकलन के दौरान -grecord-gcc-switches पास करना होगा। DWARF ही, मैंने libdwarf लाइब्रेरी को पार्स किया, जो कि libble के साथ बंडल में आती है। DWARF से संकलन कमांड के अलावा, आप अन्य फ़ाइलों पर हमारे ईटी की निर्भरता के बारे में जानकारी प्राप्त कर सकते हैं। लेकिन मैंने इस कार्यान्वयन को कई कारणों से मना कर दिया:

• पुस्तकालय काफी भारी हैं
• निर्भरता पार्सिंग के साथ ~ 500 ईटी से संकलित डीडब्ल्यूएआरएफ आवेदन को 10 सेकंड से थोड़ा अधिक समय लगा

आवेदन शुरू करने के लिए 10 सेकंड बहुत अधिक है। कुछ विचार के बाद, मैंने DWARF को पार्स करने के compile_commands.json के तर्क को फिर से लिखा। इस फाइल को केवल अपने CMakeLists.txt set(CMAKE_EXPORT_COMPILE_COMMANDS ON) जोड़कर उत्पन्न किया जा सकता है। इस प्रकार, हमें वह सारी जानकारी मिल जाती है जिसकी हमें आवश्यकता होती है।

निर्भरता से निपटने

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

क्लैंग और जीसीसी में कई विकल्प हैं जो तथाकथित डिपफाइल्स को लगभग मुफ्त में उत्पन्न करते हैं। ये फाइलें फाइलों के बीच निर्भरता को हल करने के लिए मेक और निंजा बिल्ड सिस्टम का उपयोग करती हैं। Depfiles का एक बहुत ही सरल प्रारूप है:

 CMakeFiles/lib_efsw.dir/libs/efsw/src/efsw/DirectorySnapshot.cpp.o: \ /home/ddovod/_private/_projects/jet/live/libs/efsw/src/efsw/base.hpp \ /home/ddovod/_private/_projects/jet/live/libs/efsw/src/efsw/sophist.h \ /home/ddovod/_private/_projects/jet/live/libs/efsw/include/efsw/efsw.hpp \ /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/string \ /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0/bits/c++config.h \ /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0/bits/os_defines.h \ ... 

संकलक इन फ़ाइलों को प्रत्येक ईटी के लिए ऑब्जेक्ट फ़ाइलों के बगल में रखता है, यह हमारे लिए है कि हम उन्हें पार्स करें और उन्हें हैशमैप में डालें। एक ही 500 ईटी के लिए कुल पार्सिंग संकलन compile_commands.json + depfiles 1 सेकंड से थोड़ा अधिक लेता है। सब कुछ काम करने के लिए, हमें संकलन विकल्प में सभी प्रोजेक्ट फ़ाइलों के लिए वैश्विक स्तर पर -MD ध्वज जोड़ने की आवश्यकता है।

निंजा से जुड़ी एक सूक्ष्मता है। यह बिल्ड सिस्टम अपनी जरूरतों के लिए -MD ध्वज की उपस्थिति की परवाह किए बिना depfiles उत्पन्न करता है। लेकिन उनके उत्पन्न होने के बाद, यह उन्हें अपने द्विआधारी प्रारूप में अनुवाद करता है, और स्रोत फ़ाइलों को हटा देता है। इसलिए, निंजा शुरू करते समय, आपको -d keepdepfile ध्वज को पास करना होगा। इसके अलावा, मेरे लिए अज्ञात कारणों से, मेक ( -MD विकल्प के साथ) के मामले में, फ़ाइल को some_file.cpp.d कहा जाता है, जबकि निंजा के साथ इसे some_file.cpp.od कहा जाता है। इसलिए, आपको दोनों संस्करणों की जांच करने की आवश्यकता है।

स्थैतिक चर स्थानांतरण

मान लें कि हमारे पास ऐसा कोड है (एक बहुत ही सिंथेटिक उदाहरण):

 // Singleton.hpp class Singletor { public: static Singleton& instance(); }; int veryUsefulFunction(int value); // Singleton.cpp Singleton& Singletor::instance() { static Singleton ins; return ins; } int veryUsefulFunction(int value) { return value * 2; } 

हम इसके लिए बहुत veryUsefulFunction फ़ंक्शन को बदलना चाहते हैं:

 int veryUsefulFunction(int value) { return value * 3; } 

जब नए कोड के साथ गतिशील पुस्तकालय में पुन: लोड किया veryUsefulFunction , तो बहुत veryUsefulFunction अलावा, स्थिर चर static Singleton ins; , और Singletor::instance विधि। नतीजतन, कार्यक्रम दोनों कार्यों के नए संस्करणों को कॉल करना शुरू कर देगा। लेकिन इस लाइब्रेरी में स्थिर ins को अभी तक इनिशियलाइज़ नहीं किया गया है, और इसलिए, पहली बार इसे एक्सेस करने पर, Singleton क्लास के कंस्ट्रक्टर को बुलाया जाएगा। बेशक, हम यह नहीं चाहते हैं। इसलिए, कार्यान्वयन ऐसे सभी चर के मूल्यों को स्थानांतरित करता है जो इसे पुराने कोड से इकट्ठे गतिशील पुस्तकालय में अपने गार्ड चर के साथ नए कोड के साथ इस बहुत गतिशील पुस्तकालय में पाता है।

एक सूक्ष्म और आमतौर पर अघुलनशील क्षण है।
मान लीजिए कि हमारे पास एक वर्ग है:

 class SomeClass { public: void calledEachUpdate() { m_someVar1++; } private: int m_someVar1 = 0; }; 

कहा जाता calledEachUpdate विधि प्रति सेकंड 60 बार कहा जाता है। हम इसे एक नया क्षेत्र जोड़कर बदलते हैं:

 class SomeClass { public: void calledEachUpdate() { m_someVar1++; m_someVar2++; } private: int m_someVar1 = 0; int m_someVar2 = 0; }; 

यदि इस वर्ग का एक उदाहरण डायनेमिक मेमोरी में या स्टैक पर स्थित है, तो कोड को पुनः लोड करने के बाद, एप्लिकेशन क्रैश होने की संभावना है। आबंटित आवृत्ति में केवल चर m_someVar1 , लेकिन रिबूट के बाद, calledEachUpdate विधि calledEachUpdate को बदलने की कोशिश m_someVar2 , जो वास्तव में इस उदाहरण से संबंधित नहीं है, जो कि अप्रत्याशित परिणामों की ओर जाता है। इस स्थिति में, राज्य स्थानांतरण तर्क प्रोग्रामर को स्थानांतरित कर दिया जाता है, जिसे किसी तरह ऑब्जेक्ट की स्थिति को सहेजना होगा और कोड को फिर से लोड करने से पहले ऑब्जेक्ट को हटा देना होगा, और रिबूट के बाद एक नया ऑब्जेक्ट बनाना होगा। पुस्तकालय onCodePreLoad और onCodePostLoad प्रतिनिधि विधियों के रूप में घटनाओं को प्रदान करता है जो कि आवेदन प्रक्रिया कर सकते हैं।

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

 void* oldVarPtr = ...; void* newVarPtr = ...; size_t oldVarSize = ...; size_t newVarSize = ...; memcpy(newVarPtr, oldVarPtr, std::min(oldVarSize, newVarSize)); 

यह बहुत सही नहीं है, लेकिन यह सबसे अच्छा है जो मैं लेकर आया हूं।

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

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

यह सब एक साथ कैसे काम करता है।

• पुस्तकालय गतिशील रूप से प्रक्रिया में लोड किए गए सभी पुस्तकालयों के हेडर पर प्रसारित होता है, और वास्तव में, कार्यक्रम ही, पार्स और फ़िल्टर वर्ण।
• इसके बाद, लाइब्रेरी अनुप्रयोग निर्देशिका में और मूल निर्देशिका में compile_commands.json फ़ाइल खोजने की कोशिश करती है, और वहां से ET के बारे में सभी आवश्यक जानकारी निकालती है।
• फ़ाइलों को ऑब्जेक्ट करने के लिए पथ को जानते हुए, लाइब्रेरी लोड करता है और पार्स करता है।
• उसके बाद, कार्यक्रम के सभी स्रोत कोड फ़ाइलों के लिए सबसे आम निर्देशिका की गणना की जाती है, और इस निर्देशिका की निगरानी पुनरावर्ती शुरू होती है।
• जब कोई फ़ाइल परिवर्तित होती है, तो लाइब्रेरी यह देखने के लिए देखती है कि क्या यह निर्भरता के हैशमैप में है, और यदि वहाँ है, तो संकलित आदेशों का उपयोग करते हुए पृष्ठभूमि में परिवर्तित फ़ाइलों और उनकी निर्भरता की कई संकलन प्रक्रियाओं को शुरू करता है।
• जब प्रोग्राम आपको कोड को फिर से लोड करने के लिए कहता है (मेरे आवेदन में, संयोजन Ctrl+r इसे सौंपा गया है), पुस्तकालय संकलन प्रक्रियाओं के पूरा होने का इंतजार करता है और सभी नई वस्तुओं को गतिशील पुस्तकालय से जोड़ता है।
• इस लायब्रेरी को तब dlopen फ़ंक्शन dlopen प्रक्रिया पता स्थान में लोड किया जाता है।
• प्रतीकों पर जानकारी इस पुस्तकालय से भरी हुई है, और इस पुस्तकालय से प्रतीकों के सेट का पूरा चौराहा और पहले से ही प्रक्रिया में रहने वाले प्रतीकों को या तो फिर से लोड किया गया है (यदि यह एक फ़ंक्शन है) या स्थानांतरित (यदि यह एक स्थिर चर है)।

यह बहुत अच्छी तरह से काम करता है, खासकर जब आप जानते हैं कि हुड के नीचे क्या है और क्या उम्मीद है, कम से कम उच्च स्तर पर।

व्यक्तिगत रूप से, मैं लिनक्स के लिए इस तरह के समाधान की कमी से बहुत आश्चर्यचकित था, क्या वास्तव में किसी को इसमें दिलचस्पी है?

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

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