Mach-O फ़ाइलों को लिंक करने और डाउनलोड करने के लिए ट्रिक्स

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

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

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

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

हम इस परिचय को समाप्त करते हैं और कुछ चालों पर चर्चा करते हैं जो माच-ओ प्रारूप हमें प्रदान कर सकते हैं।

स्थापना नाम

विंडोज और लिनक्स पर, गतिशील पुस्तकालयों को उनके नाम (उदाहरण के लिए, libc.so ) द्वारा संदर्भित किया जाता है, जिसके बाद गतिशील लिंकर का कार्य मानक पुस्तकालय निर्देशिकाओं में से एक में मिलान नाम के साथ एक पुस्तकालय खोजना है। डार्विन तुरंत (लगभग) पूर्ण पथ का उपयोग लाइब्रेरी फ़ाइल के बजाय करता है, जिसे इस लाइब्रेरी के लिए इंस्टॉल नाम कहा जाता है। संभवतः, यह dylib [dylib अपहरण] के प्रतिस्थापन को रोकने के लिए किया गया था - एक हमला जिसमें एक नकली dylib को एक निर्देशिका में रखा गया है जिसमें यह वास्तविक की तुलना में एक गतिशील लिंकर द्वारा पाया जाएगा, जो नकली dylib को कार्यक्रम की ओर से मनमाने कोड को निष्पादित करने की अनुमति देता है, जिसने इस प्रकार आश्वस्त किया। dylib डाउनलोड करें।

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

-dylib_install_name को लिंक करते समय, आप ld -dylib_install_name या -dylib_install_name विकल्पों का उपयोग करके इसका इंस्टॉलेशन नाम निर्दिष्ट करते हैं:

 $ ld -o libfoo.dylib foo.o -install_name /usr/local/lib/libfoo.dylib 

अब जब आप एक अन्य मच-ओ फाइल ( libbar.dylib कहते हैं) को libfoo.dylib से libfoo.dylib , तो ld libfoo इंस्टॉलेशन नाम - libbar - libbar निर्भरता libbar में libbar , और जहां डाइल्ड है रनटाइम पर libfoo तलाश करेगा।

सिस्टम लाइब्रेरी के लिए पूर्ण पथ का उपयोग करना पर्याप्त है, जो वास्तव में, फ़ाइल सिस्टम में पहले से ज्ञात स्थानों में स्थापित हैं; लेकिन पुस्तकालयों के साथ जो ऐप बंडल के हिस्से के रूप में आते हैं, एक समस्या है। यद्यपि प्रत्येक एप्लिकेशन यह मान सकता है कि यह /Applications/AppName.app में स्थापित किया जाएगा, आम तौर पर बोल रहा है, इसका मतलब है कि एप्लिकेशन असेंबली पोर्टेबल हैं और स्वतंत्र रूप से फाइल सिस्टम के चारों ओर ले जाया जा सकता है, इसलिए ऐसी असेंबली के अंदर विशिष्ट पुस्तकालय पथ नहीं हो सकता है पहले से जाना जा सकता है।

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

 $ ld -o runme -rpath @executable_path/../Frameworks -rpath @executable_path/../bin/lib 

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

चक्रीय निर्भरता

जब किसी प्रोजेक्ट का स्रोत कोड कई फाइलों पर कब्जा कर लेता है, तो यह पूरी तरह से सामान्य है यदि ये फाइलें एक-दूसरे पर परस्पर निर्भर हैं। यह तब तक ठीक काम करता है जब तक कि इन सभी फाइलों को एक एकल बाइनरी में संकलित किया जाता है - एक निष्पादन योग्य फ़ाइल या लाइब्रेरी। क्या काम नहीं करता है जब कई गतिशील पुस्तकालय एक दूसरे पर निर्भर होते हैं।

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

सिद्धांत रूप में, परिपत्र निर्भरताएं ठीक काम करना चाहिए: एक गतिशील लिंकर पहले से ही जानता है कि प्रत्येक पुस्तकालय को केवल एक बार कैसे लोड किया जाए, इसलिए इसमें अनंत पुनरावृत्ति की समस्या नहीं होगी। समस्या यह है कि ऐसे पुस्तकालयों को केवल लिंक नहीं किया जा सकता है, क्योंकि प्रत्येक लिंकर कॉल केवल एक पुस्तकालय बनाता है, और किसी भी बायनेरिज़ को लिंक करते समय, इसकी सभी निर्भरताएं जो पहले से ही लिंक की गई हैं, उन्हें लिंकर में स्थानांतरित किया जाना चाहिए। हमें पहले अपने एक पुस्तकालय को लिंक करना होगा, और इस समय अन्य अभी तक तैयार नहीं हैं, इसलिए हम उन्हें लिंकर में स्थानांतरित नहीं कर पाएंगे।

यहाँ पर ट्रिक इन लाइब्रेरियों में से कुछ (या सरलता, सभी के लिए) को दो बार लिंक करने की है। पहली बार, लिंक करने वाले को लापता निर्भरता को अनदेखा करने के लिए कहें, और वास्तव में, निर्भरता को पास न करें:

 $ ld -o libfoo.dylib foo.o -flat_namespace -undefined suppress $ ld -o libbar.dylib bar.o -flat_namespace -undefined suppress 

(नीचे देखें -flat_namespace ।)

बेशक, यदि आप परिणामस्वरूप dylibs को सीधे उपयोग करने का प्रयास करते हैं, तो आपको रन समय पर गतिशील लिंक त्रुटियां मिलेंगी। इसके बजाय, इन पुस्तकालयों को दूसरी बार लिंक करें, परिणामी dylibs को निर्भरता के रूप में पारित करें:

 $ ld -o libfoo.dylib foo.o libbar.dylib $ ld -o libbar.dylib bar.o libfoo.dylib 

इस बार, लिंकर सभी पात्रों को देखता है, इसलिए हम उसे त्रुटियों को अनदेखा करने के लिए नहीं कहते हैं (और यदि कुछ अक्षर वास्तव में गायब हैं, तो आपको एक त्रुटि मिलेगी)।

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

यहाँ एक और विवरण आरंभीकरण क्रम है। कोई भी कोड __attribute__((constructor)) कंपाइलर मैजिक कमांड (इस तरह के इनिशियलाइज़र्स की सूची __mod_init_func से Mach-O फाइल में पड़ती है) का उपयोग करके __mod_init_func की __mod_init_func । बाइनरी को लोड करते समय इन कार्यों को डाईल्ड द्वारा कहा जाता है जिसमें वे main() कॉल करने से पहले स्थित होते हैं। आमतौर पर, प्रत्येक लाइब्रेरी के इनिशियलाइज़र को उसकी निर्भरता के इनिशियलाइज़र के बाद निष्पादित किया जाता है, इसलिए प्रत्येक इनिशियलाइज़र यह उम्मीद कर सकता है कि निर्भरता लाइब्रेरी पहले से ही इनिशियलाइज़ हो चुकी है और काम करने के लिए तैयार है। बेशक, यह चक्रीय निर्भरता के लिए गारंटी नहीं दी जा सकती है; डाइल्ड अपने इनिशियलाइज़र को किसी क्रम में निष्पादित करेगा। आप इस आदेश को अनुकूलित करने के लिए निर्भरता को ऊपर की ओर निर्भरता के रूप में चिह्नित कर सकते हैं; डाइल्ड उन पुस्तकालयों को आरम्भ करेगा, जिन्हें किसी ने अपनी निर्भरता के रूप में चिह्नित किया है, अंतिम। इसलिए, libfoo को libfoo बाद इनिशियलाइज़ करने के लिए, उन्हें इस तरह से लिंक करें:

 $ ld -o libfoo.dylib foo.o libbar.dylib $ ld -o libbar.dylib bar.o -upward_library libfoo.dylib 

इसे और अधिक सुविधाजनक बनाने के लिए, हमारे पास एक डार्लिंग CMake-function है, जिसे add_circular कहा जाता है, जो सभी कठिनाइयों का ख्याल रखता है और आपको इसे बस और घोषित रूप से उपयोग करने की अनुमति देता है:

 set(DYLIB_INSTALL_NAME "/usr/lib/system/libdispatch.dylib") add_circular(libdispatch_shared FAT SOURCES ${dispatch_SRCS} SIBLINGS system_c system_kernel system_malloc system_blocks system_pthread system_dyld system_duct unwind platform compiler_rt UPWARD objc ) 

दो-स्तरीय चरित्र नाम स्थान

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

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

दो-स्तरीय नामस्थान को "फ्लैट नेमस्पेस" का उपयोग करके बदलकर बंद किया जा सकता है (इसका एक कारण यह है कि दो-स्तरीय नामस्थान का उपयोग करने का मतलब है कि लिंकिंग के दौरान प्रत्येक वर्ण को अनुमति दी जानी चाहिए, इसलिए एक फ्लैट नाम स्थान के लिए आवश्यक है -undefined_suppress , जैसे कि हमने ऊपर देखा)। Ld में दो फ़्लैग होते हैं जो लिंक करने के दौरान दो-स्तरीय नामस्थान को अक्षम करने में सक्षम होते हैं: -flat_namespace , जो केवल एक Mach-O फ़ाइल को प्रभावित करता है, और -force_flat_namespace , जो केवल निष्पादन योग्य फ़ाइलों के साथ काम करता है, पुस्तकालयों का नहीं, और एक फ्लैट का उपयोग करने के लिए पूरी प्रक्रिया को मजबूर करता है। नाम स्थान। इसके अलावा, आप DYLD_FORCE_FLAT_NAMESPACE को वातावरण चर DYLD_FORCE_FLAT_NAMESPACE सेट करके रनटाइम पर एक फ्लैट नेमस्पेस का उपयोग करने के लिए मजबूर कर सकते हैं।

दो-स्तरीय नामस्थान का उपयोग करने की एक विशेषता यह है कि आपको हमेशा प्रत्येक माच-ओ को सभी पुस्तकालयों और रूपरेखाओं से स्पष्ट रूप से जोड़ना होगा, जिस पर यह निर्भर करता है। उदाहरण के लिए, यदि आप AppKit से लिंक करते हैं, तो आप केवल Foundation का उपयोग नहीं कर सकते हैं; आपको उसे स्पष्ट रूप से लिंक करना होगा। एक अन्य विशेषता यह है कि एक पुस्तकालय या ढांचे के लेखक के रूप में, आप निर्भरता श्रृंखला के साथ प्रतीक "डाउन" के कार्यान्वयन को स्वतंत्र रूप से स्थानांतरित नहीं कर सकते हैं, जैसा कि आप करने के लिए अभ्यस्त हो सकते हैं (उदाहरण के लिए, आप बस AppKit से फाउंडेशन तक कोड को स्थानांतरित नहीं कर सकते हैं)। इसकी अनुमति देने के लिए, Mach-O, ld और dyld में कई अतिरिक्त विशेषताएं हैं, जैसे उप-लाइब्रेरीज़ , वर्णों का पुन: निर्यात और मेटा-वर्ण ।

उप पुस्तकालयों

उप-पुस्तकालयों - एक तंत्र जो एक पुस्तकालय ( मुखौटा पुस्तकालय [छाता पुस्तकालय] या छाता पुस्तकालय [छाता पुस्तकालय]) को किसी अन्य पुस्तकालय को इसकी कार्यक्षमता के हिस्से के कार्यान्वयन को सौंपने की अनुमति देता है (इसे उप-पुस्तकालय [उप-पुस्तकालय कहा जाता है)); या, यदि आप इसे दूसरी तरफ से देखते हैं, तो पुस्तकालय को सार्वजनिक रूप से किसी अन्य पुस्तकालय द्वारा प्रदान किए गए प्रतीकों को फिर से निर्यात करने की अनुमति देता है।

मुख्य स्थान जहां इसका उपयोग किया जाता है, फिर से, इसके उप-पुस्तकालयों के साथ libSystem जो /usr/lib/system ; लेकिन इसका उपयोग पुस्तकालयों के किसी भी जोड़े के साथ किया जा सकता है:

 $ ld -o libfoo.dylib foo.o -lobjc -sub_library libobjc # : $ ld -o libfoo.dylib foo.o -reexport-lobjc 

केवल उस लाइब्रेरी से लिंक करने की तुलना में इसे प्रभावित करने वाली बात यह है कि LC_REEXPORT_DYLIB कमांड को सामान्य LC_LOAD_DYLIB बजाय परिणामी फ़ाइल में लिखा जाता है (लिंकिंग में उप-लाइब्रेरी से प्रतीकों को छाता लाइब्रेरी में कॉपी नहीं किया जाता है, इसलिए यह भी नहीं होता है। लिंक अगर नए पात्रों को बाद में सबलेक्टर्स में जोड़ा जाता है)। रनटाइम के दौरान, LC_REEXPORT_DYLIB भी LC_REEXPORT_DYLIB समान काम करता है: dyld उप-लायब्रेरी को लोड करेगा और इसके पात्रों को बाकी (लेकिन LC_LOAD_DYLIB विपरीत, दो-स्तरीय नेमस्पेस के संदर्भ में, वर्ण छाता लाइब्रेरी से आएंगे) उपलब्ध LC_LOAD_DYLIB ।

LC_REEXPORT_DYLIB बारे में वास्तव में क्या अलग है जब आप किसी अन्य लायब्रेरी को libfoo से लिंक करते हैं तो ld क्या करता है: इसके बजाय सभी ऑब्जेक्ट और dylib फ़ाइलों में प्रतीकों को libfoo गया था, जो ld थे, ld भी खुलेगा और फिर से निर्यात किए गए उप-सीमाओं को देखेगा (इसमें) libobjc उदाहरण)।

वह कैसे जानती है कि उसे कहाँ देखना है? libfoo.dylib में बचाई गई एकमात्र चीज़ है स्थापना नाम libobjc.dylib , इसलिए ld इसे खोजने की अपेक्षा करता है। इसका मतलब यह है कि पुस्तकालय को किसी अन्य चीज के लिए उप-पुस्तकालय के रूप में उपयोग करने से पहले इसे अपने स्थान पर स्थापित किया जाना चाहिए; यह libobjc जैसी सिस्टम लाइब्रेरी के लिए ठीक काम करता है, लेकिन यह बहुत ही असुविधाजनक या पूरी तरह से असंभव हो सकता है यदि आप अपनी खुद की उप-लाइब्रेरी को फिर से निर्यात करने की कोशिश कर रहे हैं।

इस समस्या को हल करने के लिए, ld -dylib_file विकल्प प्रदान करता है, जो आपको लिंक करने के दौरान उपयोग करने के लिए एक अलग dylib पथ निर्दिष्ट करने की अनुमति देता है:

 $ ld -o libfoo.dylib foo.o -reexport_library /path/to/libsubfoo.dylib $ ld -o libbar.dylib bar.o libfoo.dylib -dylib_file @executable_path/lib/foo/libsubfoo.dylib:/path/to/libsubfoo.dylib 

यद्यपि libSystem और कुछ अन्य सिस्टम लाइब्रेरी अपने उप-पुस्तकालयों को फिर से निर्यात करते हैं, आपको -dylib_file पर प्रत्येक निष्पादन योग्य फ़ाइलों को लिंक करते समय -dylib_file का उपयोग करने की आवश्यकता नहीं है; इसका कारण यह है कि सिस्टम लाइब्रेरी पहले से ही उनके इंस्टॉलेशन नाम के अनुसार स्थापित हैं। लेकिन जब लिनक्स पर डार्लिंग का निर्माण करते हैं, तो हमें प्रत्येक ld कॉल के लिए कुछ -dylib_file विकल्प (और अन्य सामान्य तर्क) पास करने होंगे। हम इसे एक विशेष फ़ंक्शन के साथ करते हैं जो add_darling_library , add_darling_executable और अन्य का उपयोग करते समय स्वचालित रूप से लागू होता है।

पुन: निर्यात करने वाले पात्र

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

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

आप अपने -reexported_symbols_list विकल्प का उपयोग करके -reexported_symbols_list जाने वाले वर्णों की एक सूची पास कर सकते हैं:

 $ echo .objc_class_name_NSObject > reexport_list.exp $ ld -o CoreFoundation CFFiles.o -lobjc -reexported_symbols_list reexport_list.exp 

हालांकि कुछ प्रतीकों को फिर से निर्यात करना सभी प्रतीकों को फिर से निर्यात करने के समान लगता है, जिस तंत्र द्वारा इसे लागू किया जाता है वह उप-पुस्तकालयों के काम करने के तरीके से बहुत अलग है। कोई विशेष LC_*_DYLIB कमांड का उपयोग नहीं किया जाता है; इसके बजाय, एक विशेष अप्रत्यक्ष प्रतीक ( N_INDIR ध्वज द्वारा इंगित) को नाम तालिका में डाला गया है, और यह इस पुस्तकालय में परिभाषित प्रतीक की तरह व्यवहार करता है। यदि पुस्तकालय स्वयं इस प्रतीक का उपयोग करता है, तो नाम की तालिका में दूसरी , "अनिश्चित" प्रति दिखाई देगी (जैसा कि यह बिना किसी पुन: निर्यात के साथ होता है)।

वर्णों के स्पष्ट पुन: निर्यात का उपयोग करते समय ध्यान रखने वाली एक महत्वपूर्ण बात यह है कि आपको विभिन्न वास्तुशिल्प के लिए अलग-अलग नामों से पात्रों को फिर से निर्यात करने की आवश्यकता है। वास्तव में, .objc_class_name_NSObject और x86-64 के लिए ऑब्जेक्टिव-सी और ऑब्जेक्टिव-सी बाइनरी इंटरफेस [ABI] के लिए [नेम मैनिंग कन्वेंशन] का नामकरण कन्वेंशन अलग है, इसलिए i386 पर आपको केवल .objc_class_name_NSObject , और x86-64 पर .objc_class_name_NSObject । _OBJC_CLASS_$_NSObject , _OBJC_IVAR_$_NSObject.isa और _OBJC_METACLASS_$_NSObject । उप-पुस्तकालयों का उपयोग करते समय आपको इसके बारे में नहीं सोचना चाहिए, क्योंकि प्रत्येक आर्किटेक्चर के लिए सभी उपलब्ध प्रतीक स्वचालित रूप से फिर से निर्यात किए जाते हैं।

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

. ld , , dylib- lipo:

 $ ld -o CF_i386.dylib CFFiles.o -arch i386 -lobjc -reexported_symbols_list reexport_i386.exp $ ld -o CF_x86-64.dylib CFFiles.o -arch x86_64 -lobjc -reexported_symbols_list reexport_x86_64.exp $ lipo -arch i386 CF_i386.dylib -arch x86_64 CF_x86-64.dylib -create -output CoreFoundation 

Darling CMake- add_separated_framework , lipo, CMake- Core Foundation :

 add_separated_framework(CoreFoundation CURRENT_VERSION SOURCES ${cf_sources} VERSION "A" DEPENDENCIES objc system icucore LINK_FLAGS # ...    ) set_property(TARGET CoreFoundation_i386 APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/reexport_i386.exp") set_property(TARGET CoreFoundation_x86_64 APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-reexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/reexport_x86_64.exp") 

-

- – , , Apple , .

Mach-O- macOS, , -mmacosx-version-min=10.x ( iOS, tvOS, watchOS , Apple ). ; , AVAILABLE_MAC_OS_X_VERSION_10_13_AND_LATER C++ libstdc++ ( GNU) libc++ ( LLVM). , Mach-O. , ld -macosx_version_min ( m ), Mach-O- LC_VERSION_MIN_MACOSX ( dyld, , ).

, ld -macosx_version_min , - Mach-O- . - – , $ld$ , ld, , : , . $ld$$$ . os10.5 , - – , Mach-O- , ; add , hide , install_name compatibility_version , ld , , ( ) , .

, , , ; , -, libobjc , NSObject , macOS:

 $ld$hide$os10.0$_OBJC_CLASS_$_NSObject $ld$hide$os10.0$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.0$_OBJC_METACLASS_$_NSObject $ld$hide$os10.1$_OBJC_CLASS_$_NSObject $ld$hide$os10.1$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.1$_OBJC_METACLASS_$_NSObject $ld$hide$os10.2$_OBJC_CLASS_$_NSObject $ld$hide$os10.2$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.2$_OBJC_METACLASS_$_NSObject $ld$hide$os10.3$_OBJC_CLASS_$_NSObject $ld$hide$os10.3$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.3$_OBJC_METACLASS_$_NSObject $ld$hide$os10.4$_OBJC_CLASS_$_NSObject $ld$hide$os10.4$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.4$_OBJC_METACLASS_$_NSObject $ld$hide$os10.5$_OBJC_CLASS_$_NSObject $ld$hide$os10.5$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.5$_OBJC_METACLASS_$_NSObject $ld$hide$os10.6$_OBJC_CLASS_$_NSObject $ld$hide$os10.6$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.6$_OBJC_METACLASS_$_NSObject $ld$hide$os10.7$_OBJC_CLASS_$_NSObject $ld$hide$os10.7$_OBJC_IVAR_$_NSObject.isa $ld$hide$os10.7$_OBJC_METACLASS_$_NSObject 

, , , , .

dyld – [symbol resolvers], . , , , dyld , .

ld, . .symbol_resolver :

 ;    foo _foo1: movl 1, %eax ret _foo2: movl 2, %eax ret .symbol_resolver _foo ;  -  call _condition jz .ret_foo2 movq _foo1, %rax ret .ret_foo2: movq _foo2, %rax ret ;   ,   _foo  ;   ,     , ;     . .global _foo _foo: 

C , , C:

 static int foo1() { return 1; } static int foo2() { return 2; } int foo() { //         return 0; } static void *foo_resolver() { __asm__(".symbol_resolver _foo"); return condition() ? &foo1 : &foo2; } 

( _foo foo , Darwin C, . , Mach-O Darling, ELF-, .)

_foo , ( ), foo() foo_resolver() , :

 void *foo() { __asm__(".symbol_resolver _foo"); return condition() ? &foo1 : &foo2; } 

, – - , foo() , ( int -). , , : dlsym("_foo") _foo – , , , – . , , , foo() _foo .

. Apple libplatform :

 #define _OS_VARIANT_RESOLVER(s, v, ...) \ __attribute__((visibility(OS_STRINGIFY(v)))) extern void* s(void); \ void* s(void) { \ __asm__(".symbol_resolver _" OS_STRINGIFY(s)); \ __VA_ARGS__ \ } #define _OS_VARIANT_UPMP_RESOLVER(s, v) \ _OS_VARIANT_RESOLVER(s, v, \ uint32_t *_c = (void*)(uintptr_t)_COMM_PAGE_CPU_CAPABILITIES; \ if (*_c & kUP) { \ extern void OS_VARIANT(s, up)(void); \ return &OS_VARIANT(s, up); \ } else { \ extern void OS_VARIANT(s, mp)(void); \ return &OS_VARIANT(s, mp); \ }) 

, – – ( kUP , commpage ), , , [spinlock]. , .

Darling : Mach-O- ELF- Linux, [host, , Darling] – , libX11 libcairo .

ELF- – libelfloader , ELF, , ld-linux, dyld Linux, ld-linux ELF-. libelfloader Mach-O /usr/lib/darling/libelfloader.dylib Darwin-chroot-; , Darwin-.

, libelfloader Mach-O ELF. ( _elfcalls ), libSystem , Darwin , ELF- Linux. «» Darwin Linux – , C ( libSystem_c glibc , ).

ELF- Darwin, - libelfloader API _elfcalls->dlsym_fatal(_elfcalls->dlopen_fatal("libX11.so"), "XOpenDisplay") . , wrapgen , ELF- , , The Cocotron – Linux – . wrapgen ELF- (, libX11.so ), :

 #include <elfcalls.h> extern struct elf_calls* _elfcalls; static void* lib_handle; __attribute__((constructor)) static void initializer() { lib_handle = _elfcalls->dlopen_fatal("libX11.so"); } __attribute__((destructor)) static void destructor() { _elfcalls->dlclose_fatal(lib_handle); } void* XOpenDisplay() { __asm__(".symbol_resolver _XOpenDisplay"); return _elfcalls->dlsym_fatal(lib_handle, "XOpenDisplay"); } 

Mach-O- /usr/lib/native/libX11.dylib , Mach-O- , libX11.so , Mach-O. , CMake- wrap_elf , wrapgen, Mach-O- /usr/lib/native : wrap_elf(X11 libX11.so) libX11 , Mach-O-.

Linux . , Darling , Darwin Linux, . Darling – Darwin ( , Darwin); , , , Darwin, libSystem , dyld, XNU launchd, , , commpage. , libsystem_kernel , , Linux, «» Darwin- – Linux GNU/Linux . Linux- , Linux ( X server) , [witnessing a magic trick] – libelfloader , wrapgen, , . , , , , , .

- , Mach-O-, ld . ( , – , Apple, , .)

, , , , [order file], ld :

 $ ld -o libfoo.dylib foo.o -order_file foo.order 

-reexported_symbols_list , , -order_file , :

 symbol1 symbol2 #  . # #    ,     , #    (   C)  #        . foo.o: _static_function3 #  ,   ,     #     ;    #        #  lipo,     # . i386:symbol4 

( , , ) «» . , , , , .subsections_via_symbols , Mach-O- , , , , .

, Apple – libdispatch . libdispatch , «OS object», , . Objective-C, libdispatch ( Core Foundation), libdispatch - Objective-C- , Objective-C-. , dispatch_data_t NSData * API Cocoa ( ).

, , Objective-C- OS object vtables . , DISPATCH_OBJECT_TFB , , Objective-C libdispatch -, isa vtable - dispatch_object object :

 #define DISPATCH_OBJECT_TFB(f, o, ...) \ if (slowpath((uintptr_t)((o)._os_obj->os_obj_isa) & 1) || \ slowpath((Class)((o)._os_obj->os_obj_isa) < \ (Class)OS_OBJECT_VTABLE(dispatch_object)) || \ slowpath((Class)((o)._os_obj->os_obj_isa) >= \ (Class)OS_OBJECT_VTABLE(object))) { \ return f((o), ##__VA_ARGS__); \ } 

, , libdispatch .

( ) – DYLD_INSERT_LIBRARIES , dyld Mach-O- . , , , DYLD_FORCE_FLAT_NAMESPACE .

, , - . ( ), dlsym() RTLD_NEXT , :

 int open(const char* path, int flags, mode_t mode) { printf(" open(%s)\n", path); // "  " if (strcmp(path, "foo") == 0) { path = "bar"; } int (*original_open)(const char *, int, mode_t); original_open = dlsym(RTLD_NEXT, "open"); return original_open(path, flags, mode); } 

, dyld , dyld- [dyld iterposing]. Mach-O- __interpose , dyld , – .

, – , __interpose – [implicit interposing]. , __interpose ( ), dyld . , dyld- , - . , dyld , - , - ( Mach-O-):

 static int my_open(const char* path, int flags, mode_t mode) { printf("Called open(%s)\n", path); // "  " if (strcmp(path, "foo") == 0) { path = "bar"; } //    ,    //  open()      my_open(). return open(path, flags, mode); } //      __interpose __attribute__ ((section ("__DATA,__interpose"))) static struct { void *replacement, *replacee; } replace_pair = { my_open, open }; 

, – – Mach-O- - [relocation table]. , dyld ( ), .

, dyld_dynamic_interpose , :

 typedef struct { void *replacement, *replacee; } replacement_tuple; extern const struct mach_header __dso_handle; extern void dyld_dynamic_interpose(const struct mach_header*, const replacement_tuple replacements[], size_t count); void interpose() { replacement_tuple replace_pair = { my_open, open }; dyld_dynamic_interpose(&__dso_handle, &replace_pair, 1); } 

, , , .

DYLD_INSERT_LIBRARIES dyld- Objective-C, C, - , Objective-C- ( IMP ), Objective-C , method swizzling ( isa swizzling ).

Darling xtrace, .

Darwin Darwin ( – BSD Mach- [Mach traps]). libsystem_kernel , ABI userspace. Darling, libsystem_kernel Darwin Linux Darling-Mach , Linux, Mach .

strace, Linux, , Linux-; strace Darwin, Darling, Linux, Darwin ( Linux, ELF- ). , Darwin Linux , , Darwin – , – .

, xtrace . strace, , ptrace() API, xtrace . DYLD_INSERT_LIBRARIES=/usr/lib/darling/libxtrace.dylib , - [trampoline functions] , . xtrace , strace, , , :

 Darling [~]$ xtrace arch <......> [223] mach_timebase_info_trap (...) [223] mach_timebase_info_trap () -> KERN_SUCCESS [223] issetugid (...) [223] issetugid () -> 0 [223] host_self_trap () [223] host_self_trap () -> port right 2563 [223] mach_msg_trap (...) [223] mach_msg_trap () -> KERN_SUCCESS [223] _kernelrpc_mach_port_deallocate_trap (task=2563, name=-6) [223] _kernelrpc_mach_port_deallocate_trap () -> KERN_SUCCESS [223] ioctl (...) [223] ioctl () -> 0 [223] fstat64 (...) [223] fstat64 () -> 0 [223] ioctl (...) [223] ioctl () -> 0 [223] write_nocancel (...) i386 [223] write_nocancel () -> 5 [223] exit (...) 

, BSD Mach. , write() exit() , Linux-, . , Mach- ioctl - /dev/mach , ; BSD- ioctl() , stdio , stdin stdout ( tty) readlink() /proc/self/fd/ .

Mach-O, , dyld. :

• , , dylib, , . ld -bundle_loader .
• , LC_LOAD_DYLIB , LC_REEXPORT_DYLIB LC_DYLIB_ID , [compatibility version, current version] , – , . ld -current_version -compatibility_version , . dyld , , , .
• , Mach-O [source version]. , LC_SOURCE_VERSION . ld -source_version , , Mach-O- – -add_source_version -no_source_version .
• Info.plist __info_plist Mach-O- [codesign] , Info.plist . ad-hoc Security.framework, , CFBundle / NSBundle API, , , .

, , , ld dyld , « », libSystem , -. /usr/lib/ .