सबसे छोटे के लिए एआरएम: संकलन और लिंकर की सूक्ष्मता

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

पिछले लेख:

• सबसे छोटे के लिए एआरएम
• सबसे छोटे के लिए एआरएम: क्या समय है?

लेख से कोड उदाहरण: https://github.com/farcaller/arm-demos



जब हम स्रोत फ़ाइल संकलित करते हैं, तो आउटपुट पर हमें एक ऑब्जेक्ट फ़ाइल मिलती है, जिसमें आमतौर पर डेटा के साथ कई खंड होते हैं। चार सबसे आम खंड हैं:

• .text - संकलित मशीन कोड;
• .data - वैश्विक और स्थिर चर;
• .rodata - अपरिवर्तनीय डेटा के लिए .data का एक एनालॉग;
• .bss - वैश्विक और स्थिर चर जिसमें स्टार्टअप पर एक शून्य मान होता है।

इस चक्र के हिस्से के रूप में हमारे साथ काम करने वाली बाइनरी फ़ाइलों में, दो और खंड अक्सर सामने आएंगे:

• .comment - संकलक संस्करण के बारे में जानकारी;
• .ARM.attributes - ARM- विशिष्ट फ़ाइल विशेषताएँ

वर्गों के अलावा, ऑब्जेक्ट फ़ाइल में एक और महत्वपूर्ण इकाई है: एक प्रतीक तालिका। यह एक प्रकार का हैश: नाम - पता (और अतिरिक्त विशेषताएँ) है। उदाहरण के लिए, उदाहरण के लिए, सभी निर्यात किए गए फ़ंक्शंस और उनके पते (जो कि .text सेक्शन में कहीं इंगित करेंगे) इंगित किए गए हैं।

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

भीतर देख लो

पहले उदाहरण के रूप में, हम निम्नलिखित C कोड module_a.c : module_a.c :

 static int local_function(); int external_counter; static int counter; static int preset_counter = 5; const int constant = 10; int public_function() { volatile int i = 3 + constant; ++external_counter; return local_function() * i; } static int local_function() { ++counter; ++preset_counter; return counter + preset_counter; } 

इसे संकलित करें और देखें कि हमें कौन से सेक्शन मिले:

 % rake 'show:sections[a]' arm-none-eabi-gcc -mthumb -O2 -mcpu=cortex-m0 -c module_a.c -o build/module_a.o arm-none-eabi-objdump build/module_a.o -h build/module_a.o: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000034 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000004 00000000 00000000 00000068 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000004 00000000 00000000 0000006c 2**2 ALLOC 3 .rodata 00000004 00000000 00000000 0000006c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .comment 00000071 00000000 00000000 00000070 2**0 CONTENTS, READONLY 5 .ARM.attributes 00000031 00000000 00000000 000000e1 2**0 CONTENTS, READONLY 

जैसा कि हम देखते हैं, छह खंड हैं, जिनका उद्देश्य पहले से ही कम या ज्यादा ज्ञात है। दूसरी पंक्ति सेक्शन की विशेषताएँ हैं, वे लिंक करते समय बाद में अधिक दिलचस्प होंगे। आइए देखें कि इन वर्गों में कौन से वर्ण परिभाषित हैं:

 % rake 'show:symbols:text[a]' arm-none-eabi-objdump build/module_a.o -j .text -t build/module_a.o: file format elf32-littlearm SYMBOL TABLE: 00000000 ld .text 00000000 .text 00000000 g F .text 00000034 public_function 

परामर्श के लिए objdump पर मनुष्य को खोलें। इस खंड में, हम दो वर्णों को देखते हैं: .text एक डिबगिंग वर्ण है जो अनुभाग की शुरुआत को इंगित करता है, public_function एक ऐसा चरित्र है जो हमारे कार्य को इंगित करता है। local_function लिए local_function प्रतीक local_function , क्योंकि फ़ंक्शन को static रूप में घोषित किया गया है, अर्थात, इसे ऑब्जेक्ट फ़ाइल के बाहर निर्यात नहीं किया गया है।

 % rake 'show:symbols:data[a]' arm-none-eabi-objdump build/module_a.o -j .data -j .bss -t build/module_a.o: file format elf32-littlearm SYMBOL TABLE: 00000000 ld .data 00000000 .data 00000000 ld .bss 00000000 .bss 00000000 l O .data 00000004 preset_counter 00000000 l O .bss 00000004 counter 

.bss और .bss वर्गों में हमारे दो काउंटर हैं - preset_counter और counter । वे अलग-अलग वर्गों में हैं, क्योंकि preset_counter का प्रारंभिक मूल्य है, जो कि preset_counter में संग्रहीत है। "

 % rake 'show:contents[a,.data]' arm-none-eabi-objdump build/module_a.o -j .data -s build/module_a.o: file format elf32-littlearm Contents of section .data: 0000 05000000 

counter कोई मूल्य नहीं है, इसलिए यह शून्य पर शुरू होता है और .bss अनुभाग में समाप्त होता है। .bss खंड स्वयं फ़ाइल में भौतिक रूप से मौजूद नहीं है, क्योंकि इसकी सामग्री हमेशा तय होती है - ये शून्य हैं। यदि आपने कोड में char buffer[1024] घोषणा की है, तो संकलक को ऑब्जेक्ट फ़ाइल के लिए खाली जगह के किलोबाइट लिखना होगा, जिसका कोई मतलब नहीं है।

इस बिंदु पर, आपके पास एक सवाल हो सकता है - बाहरी_काउंटर कहां गया?

 % rake 'show:symbols:all[a]' arm-none-eabi-objdump build/module_a.o -t build/module_a.o: file format elf32-littlearm SYMBOL TABLE: 00000000 l df *ABS* 00000000 module_a.c 00000000 ld .text 00000000 .text 00000000 ld .data 00000000 .data 00000000 ld .bss 00000000 .bss 00000000 ld .rodata 00000000 .rodata 00000000 l O .data 00000004 preset_counter 00000000 l O .bss 00000004 counter 00000000 ld .comment 00000000 .comment 00000000 ld .ARM.attributes 00000000 .ARM.attributes 00000000 g F .text 00000034 public_function 00000004 O *COM* 00000004 external_counter 00000000 g O .rodata 00000004 constant 

external_counter *COM* सेक्शन में चला गया। इस स्थिति में, इसका अर्थ है कि यह इस ऑब्जेक्ट फ़ाइल के बाहर स्थित हो सकता है। पहले से ही लिंकिंग के चरण में, ld यह पता .bss कि क्या प्रतीक को किसी अन्य फ़ाइल में घोषित किया गया है, या उसे स्वयं बनाना चाहिए - इस मामले में, .bss अनुभाग में। यह भी ध्यान दें कि .rodata const int constant । संकलक यह सुनिश्चित करता है कि कोड को इस पते पर मूल्य बदलने की आवश्यकता नहीं है, ताकि लिंकर सुरक्षित रूप से फ्लैश मेमोरी में रख सके।

हम देख सकते हैं।

 % rake 'show:contents[a,.comment]' arm-none-eabi-objdump build/module_a.o -j .comment -s build/module_a.o: file format elf32-littlearm Contents of section .comment: 0000 00474343 3a202847 4e552054 6f6f6c73 .GCC: (GNU Tools 0010 20666f72 2041524d 20456d62 65646465 for ARM Embedde 0020 64205072 6f636573 736f7273 2920342e d Processors) 4. 0030 372e3320 32303133 30333132 20287265 7.3 20130312 (re 0040 6c656173 6529205b 41524d2f 656d6265 lease) [ARM/embe 0050 64646564 2d345f37 2d627261 6e636820 dded-4_7-branch 0060 72657669 73696f6e 20313936 3631355d revision 196615] 0070 00 

संकलक संस्करण वास्तव में यहाँ लिखा गया है। हम .ARM.attributes में भी देख सकते हैं, हालांकि इसके लिए यह objdump का उपयोग करने के लायक है, लेकिन यह नहीं है:

 % rake 'show:attrs[a]' arm-none-eabi-readelf build/module_a.o -A Attribute Section: aeabi File Attributes Tag_CPU_name: "Cortex-M0" Tag_CPU_arch: v6S-M Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: small Tag_ABI_optimization_goals: Aggressive Speed 

सार्वजनिक टैग प्रलेखन को एआरएम इन्फो सेंटर में देखा जा सकता है।

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

अब जब हमने ऑब्जेक्ट फ़ाइलों के अंदर देखा है, तो आइए देखें कि कैसे ld उन्हें एक सफल एप्लिकेशन में एकत्रित करता है।

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

एम्बेडेड सिस्टम आसान होने के साथ, फर्मवेयर प्रोग्राम आपकी बाइनरी फ़ाइल लेता है और इसे USB फ्लैश ड्राइव पर अपलोड करता है। वह माचो या कल्पित बौनों की परवाह नहीं करता है, वह बाइनरी डंप के साथ काम करता है।

एक साधारण लिंकर स्क्रिप्ट लें और इसे अलग ले जाएं। layout.ld:

 MEMORY { rom(RX) : ORIGIN = 0x00000000, LENGTH = 0x8000 ram(WAIL) : ORIGIN = 0x10000000, LENGTH = 0x2000 } ENTRY(public_function) SECTIONS { .text : { *(.text) } > rom _data_start = .; .data : { *(.data) } > ram AT> rom _bss_start = .; .bss : { *(.bss) } > ram _bss_end = .; } 

डिफ़ॉल्ट लिंकर कॉन्फ़िगरेशन यह सभी उपलब्ध मेमोरी (कहीं-कहीं 32-बिट एआरएम के मामले में 0xFFFFFFFF बाइट्स) का उपयोग करने की अनुमति देता है। चलो उन मेमोरी क्षेत्रों को परिभाषित करने से शुरू करते हैं जिनका उपयोग किया जा सकता है: rom और ram । कोष्ठक में अक्षर विशेषताओं को परिभाषित करते हैं: पढ़ना, लिखना, निष्पादित करना, स्मृति आवंटन। स्क्रिप्ट में स्पष्ट रूप से निर्दिष्ट नहीं किए गए अनुभाग स्वचालित रूप से उपयुक्त विशेषताओं वाले क्षेत्रों में बिखरे होंगे। यदि अनुभाग के लिए कोई स्थान नहीं है, तो लिंकर काम करने से इनकार कर देगा, अपने व्यवहार को कुछ इस तरह से तर्क देगा: error: no memory region specified for loadable section `.data' ।

दो पैरामीटर, ORIGIN और LENGTH , क्रमशः क्षेत्र की शुरुआत और लंबाई निर्दिष्ट करते हैं, आप अभी भी विकल्प org , o , len और l को पा सकते हैं, वे बराबर हैं। मूल्य एक अभिव्यक्ति है, यानी, यह अंकगणितीय संचालन कर सकता है या प्रत्यय K , M , आदि का उपयोग कर सकता है। उदाहरण के लिए LENGTH = 0x8000 , वैकल्पिक रूप से इस तरह किया जा सकता है: l = 32K ।

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

स्रोत अनुभाग _(_) के रूप में निर्दिष्ट किए गए हैं, * चरित्र मानक तरीके से व्यवहार करता है, इसलिए प्रविष्टि *(.text) अर्थ है: सभी फ़ाइलों से .text अनुभाग।

अनुभाग में दो पते हैं: LMA (लोड मेमोरी एड्रेस) - जहां से इसे लोड किया गया है, और VMA (वर्चुअल मेमोरी एड्रेस) - यह वर्चुअल मेमोरी में किस पते पर उपलब्ध है। इसे और अधिक सरल रूप से समझाने के लिए, LMA बाइनरी फ़ाइल में दिखाई देगा, और VMA वह जगह है जहाँ वर्ण पुनर्निर्देशित किए जाएंगे, अर्थात, कोड में वर्ण का सूचक VMA पते को संदर्भित करेगा।

हम तीन वर्गों में रुचि रखते हैं - कोड, डेटा और डेटा, जो डिफ़ॉल्ट रूप से शून्य हैं। इस प्रकार, हम मेमोरी को फ्लैश करने के लिए मेमोरी, डेटा ( .data ) को फ्लैश करने के लिए कोड ( .text ) को कॉपी करते हैं, लेकिन इस धारणा पर कि वे रैम में उपलब्ध होंगे, और रैम के लिए।

.bss , सामान्य तौर पर, आरंभीकरण की आवश्यकता नहीं होती है ( UPD : वे मुझे बता देते हैं कि जैबर में क्या आवश्यक है, हमें इस बात की गारंटी देनी चाहिए कि शून्य हैं, न कि कचरा जो किसी कारण से दिखाई दिया हो), क्योंकि माइक्रोकंट्रोलर शुरू होता है स्मृति और इसलिए, शायद, शून्य पर रीसेट हो। लेकिन .data साथ .data अलग से टिंकर करना पड़ता है, समस्या दो गुना प्रकृति के कारण है। एक तरफ, विशिष्ट डेटा वहाँ संग्रहीत किया जाता है ( preset_counter मूल्य), इसलिए यह फ्लैश मेमोरी में होना चाहिए। दूसरी ओर, यह एक लिखने योग्य अनुभाग है, इसलिए इसे रैम में होना चाहिए। यह समस्या विभिन्न LMA और VMA द्वारा हल की गई है, साथ ही अतिरिक्त C कोड भी है, जो स्टार्टअप पर LMA से VMA की सामग्री की प्रतिलिपि बनाएगा। निरंतर डेटा के लिए, जो आमतौर पर .rodata सेक्शन में स्थित होते हैं, ऐसी प्रक्रिया, उदाहरण के लिए, इसकी आवश्यकता नहीं है, हम फ्लैश मेमोरी से सीधे सुरक्षित रूप से पढ़ सकते हैं।

लिंकर में एक कर्सर अवधारणा है - यह वर्तमान एलएमए है। खंड खंड की शुरुआत में, कर्सर शून्य है और धीरे-धीरे बढ़ जाता है क्योंकि नए खंड जोड़े जाते हैं। वर्तमान कर्सर मान को एक चर में संग्रहीत किया जाता है . (डॉट)।

चलिए लिंकर को चलाते हैं और इसके कार्य का परिणाम देखते हैं:

 % rake 'show:map[a]' arm-none-eabi-ld -T layout.ld -M -o build/out.elf build/module_a.o Allocating common symbols Common symbol size file external_counter 0x4 build/module_a.o Memory Configuration Name Origin Length Attributes rom 0x0000000000000000 0x0000000000008000 xr ram 0x0000000010000000 0x0000000000002000 awl *default* 0x0000000000000000 0xffffffffffffffff 

सबसे पहले, हम देखते हैं कि कैसे लिंकर "सामान्य" external_counter प्रतीक को एक अलग श्रेणी में रखता है। अगला, हम देखते हैं कि हमारी मेमोरी कॉन्फ़िगरेशन को लोड किया गया है और डिफ़ॉल्ट कॉन्फ़िगरेशन में जोड़ा गया है (जो संपूर्ण पता स्थान आवंटित करता है)।

 Linker script and memory map .text 0x0000000000000000 0x34 *(.text) .text 0x0000000000000000 0x34 build/module_a.o 0x0000000000000000 public_function 0x0000000000000034 _data_start = . 

इसके बाद, लिंकर मेमोरी को उन वर्गों में रखता है जिन्हें हमने निर्दिष्ट किया है, सबसे पहले।

 .rodata 0x0000000000000034 0x4 .rodata 0x0000000000000034 0x4 build/module_a.o 0x0000000000000034 constant .glue_7 0x0000000000000038 0x0 .glue_7 0x0000000000000000 0x0 linker stubs .glue_7t 0x0000000000000038 0x0 .glue_7t 0x0000000000000000 0x0 linker stubs .vfp11_veneer 0x0000000000000038 0x0 .vfp11_veneer 0x0000000000000000 0x0 linker stubs .v4_bx 0x0000000000000038 0x0 .v4_bx 0x0000000000000000 0x0 linker stubs .iplt 0x0000000000000038 0x0 .iplt 0x0000000000000000 0x0 build/module_a.o .rel.dyn 0x0000000000000038 0x0 .rel.iplt 0x0000000000000000 0x0 build/module_a.o 

अगले भाग ऐसे अनुभाग हैं जिनका हमने स्पष्ट रूप से संकेत नहीं दिया है - .rodata , .glue_7 , .glue_7t , .vfp11_veneer , .v4_bx , .iplt , .rel.dyn । के साथ .rodata सब कुछ स्पष्ट है, हमारे निरंतर constant को चार बाइट्स में संग्रहीत किया जाता है। शेष वर्गों के लिए, उनका अस्तित्व प्रदर्शन के लिए सभी प्रकार के समर्थन के कारण है, उदाहरण के लिए, एआरएम से थम्ब तक कूदता है। ये सभी अनुभाग खाली हैं और अंतिम छवि में नहीं आते हैं।

 .data 0x0000000010000000 0x4 load address 0x0000000000000038 *(.data) .data 0x0000000010000000 0x4 build/module_a.o 0x0000000010000004 _data_end = . 

यहां हमारा .data अनुभाग है, जैसा कि आप देख सकते हैं, यह 0x10000000 पर स्थित है, हालांकि यह भौतिक रूप से 0x38 पर संग्रहीत है (यानी, तुरंत बाद .rodata )। यहाँ हम कर्सर से पढ़े गए हमारे वैरिएबल का मान देखते हैं, _data_end ।

 .igot.plt 0x0000000010000004 0x0 load address 0x000000000000003c .igot.plt 0x0000000000000000 0x0 build/module_a.o .bss 0x0000000010000004 0x8 load address 0x000000000000003c *(.bss) .bss 0x0000000010000004 0x4 build/module_a.o COMMON 0x0000000010000008 0x4 build/module_a.o 0x0000000010000008 external_counter 0x000000001000000c _bss_end = . 

एक और खाली खंड, उसके बाद .bss

 LOAD build/module_a.o OUTPUT(build/out.elf elf32-littlearm) .comment 0x0000000000000000 0x70 .comment 0x0000000000000000 0x70 build/module_a.o 0x71 (size before relaxing) .ARM.attributes 0x0000000000000000 0x31 .ARM.attributes 0x0000000000000000 0x31 build/module_a.o 

अंत में, ld एक आउटपुट फाइल जेनरेट करता है और अनावश्यक सेक्शनों को डिस्कस करता है। सब कुछ पसंद है?

  0x0000000000000034 _data_start = . ... .data 0x0000000010000000 0x4 load address 0x0000000000000038 

.data की शुरुआत की ओर इशारा करने वाला चर वास्तव में गलत जगह की ओर इशारा करता है! लेकिन सच्चाई यह है कि, .text बाद का कर्सर इसके अंत का संकेत देता है। चर को सही ढंग से सेट करने के लिए, इसे आउटपुट सेक्शन के विवरण के अंदर ले जाना चाहिए:

 .data : { _data_start = .; *(.data) _data_end = .; } > ram AT> rom 

हम लिखते हैं और देखते हैं कि क्या बदल गया है:

 % rake 'show:map[a]' SCRIPT=layout2.ld arm-none-eabi-ld -T layout2.ld -M -o build/module_a.elf build/module_a.o ... .data 0x0000000010000000 0x4 load address 0x0000000000000038 0x0000000010000000 _data_start = . *(.data) .data 0x0000000010000000 0x4 build/module_a.o 0x0000000010000004 _data_end = . ... 

महान, अब सब कुछ जगह में है।

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

आइए कार्य को जटिल करते हैं

हमने एक मॉड्यूल का पता लगाया। आइए एक दूसरी फ़ाइल जोड़ें और देखें कि क्या परिवर्तन होता है। दूसरी फ़ाइल में पहले से ही ज्ञात module_b.cpp और कुछ C ++ कोड: module_b.cpp

 int external_counter; extern "C" int public_function(); void function_b() { external_counter += public_function(); } void function_c() { } void function_d() { } 

जैसा कि आप जानते हैं, जब C ++ कोड को संकलित किया जाता है, तो फ़ंक्शन और विधियों के नाम "मैनरिंग" से गुजरते हैं, जब नाम में तर्कों, वर्ग और नाम स्थान के प्रकार एन्कोड किए जाते हैं:

 % rake 'show:symbols:text[b]' arm-none-eabi-gcc -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -mthumb -O2 -mcpu=cortex-m0 -c module_b.cpp -o build/module_b.o arm-none-eabi-objdump build/module_b.o -j .text -t build/module_b.o: file format elf32-littlearm SYMBOL TABLE: 00000000 ld .text 00000000 .text 00000000 g F .text 00000014 _Z10function_bv 00000014 g F .text 00000002 _Z10function_cv 00000018 g F .text 00000002 _Z10function_dv 

हम अपवादों से संबंधित अतिरिक्त अनुभागों की उपस्थिति से बचने के लिए झंडे -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables के साथ कोड संकलित करते हैं। फंक्शन के नाम के अनुसार एनकोड किया गया है।

हम इस मॉड्यूल के लिए कोई मानचित्र नहीं बना सकते हैं, क्योंकि यह अपने आप नहीं बनाया जा सकता है, यह मॉड्यूल से public_function फ़ंक्शन पर निर्भर करता a । हम एक ही बार में दोनों मॉड्यूलों की रचना करते हैं:

 % rake 'show:map[a|b]' SCRIPT=layout2.ld arm-none-eabi-ld -T layout2.ld -M -o build/out.elf build/module_a.o build/module_b.o ... .text 0x0000000000000000 0x34 build/module_a.o 0x0000000000000000 public_function .text 0x0000000000000034 0x1c build/module_b.o 0x0000000000000034 function_b() 0x0000000000000048 function_c() 0x000000000000004c function_d() ... 

सामान्य वर्णों का ब्लॉक चला गया है, सभी वर्ण संगत मॉड्यूल में पाए जाते हैं। .text अनुभाग, साथ ही अन्य, एक के बाद एक व्यवस्थित किए जाते हैं।

चलो कचरा इकट्ठा करो!

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

 % rake 'show:map[a|b]' SCRIPT=layout2.ld GC=1 arm-none-eabi-ld --gc-sections -T layout2.ld -M -o build/out.elf build/module_a.o build/module_b.o Discarded input sections .rodata 0x0000000000000000 0x4 build/module_a.o COMMON 0x0000000000000000 0x0 build/module_a.o .text 0x0000000000000000 0x1c build/module_b.o .data 0x0000000000000000 0x0 build/module_b.o ... .text 0x0000000000000000 0x34 *(.text) .text 0x0000000000000000 0x34 build/module_a.o 0x0000000000000000 public_function ... 

जैसा कि आप देख सकते हैं, build/module_b.o सेक्शन को पूरी तरह से हटा दिया गया है, क्योंकि इसमें बेकार फ़ंक्शंस थे! उसी समय, लिंकर ने अप्रयुक्त स्थिरांक को पहले मॉड्यूल से फेंक दिया।

वास्तव में, यह अनुकूलन पूर्ण नहीं है, क्योंकि हम आसानी से एक साधारण प्रयोग के साथ देख सकते हैं, module_c.cpp

 void function_b(); extern "C" int public_function() { function_b(); } 

हम मॉड्यूल को मॉड्यूल c साथ बदल देंगे और देखेंगे कि क्या लिंकर अनुभाग को हटा सकता है।

 % rake 'show:map[b|c]' SCRIPT=layout2.ld GC=1 arm-none-eabi-gcc -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -mthumb -O2 -mcpu=cortex-m0 -c module_c.cpp -o build/module_c.o arm-none-eabi-ld --gc-sections -T layout2.ld -M -o build/out.elf build/module_b.o build/module_c.o Discarded input sections .data 0x0000000000000000 0x0 build/module_b.o .data 0x0000000000000000 0x0 build/module_c.o .bss 0x0000000000000000 0x0 build/module_c.o ... .text 0x0000000000000000 0x24 *(.text) .text 0x0000000000000000 0x1c build/module_b.o 0x0000000000000000 function_b() 0x0000000000000014 function_c() 0x0000000000000018 function_d() .text 0x000000000000001c 0x8 build/module_c.o 0x000000000000001c public_function 

यद्यपि यह वर्गों के भाग को बाहर फेंकना संभव था (हालांकि खाली वाले), हम अभी भी फ़ंक्शन function_c() और function_d() लिए अनमोल बाइट्स खो देते हैं, जो फ़ंक्शन_ function_b() रूप में उसी अनुभाग में समाप्त हो गया है। संकलक झंडे बचाव में आएंगे, जो फ़ंक्शन और डेटा को अलग -ffunction-sections अलग वर्गों में -ffunction-sections हैं: -ffunction-sections और -fdata-sections :

 % rake clean && rake 'show:symbols:all[b]' SPLIT_SECTIONS=1 arm-none-eabi-gcc -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -ffunction-sections -fdata-sections -mthumb -O2 -mcpu=cortex-m0 -c module_b.cpp -o build/module_b.o arm-none-eabi-objdump build/module_b.o -t build/module_b.o: file format elf32-littlearm SYMBOL TABLE: 00000000 l df *ABS* 00000000 module_b.cpp 00000000 ld .text 00000000 .text 00000000 ld .data 00000000 .data 00000000 ld .bss 00000000 .bss 00000000 ld .text._Z10function_bv 00000000 .text._Z10function_bv 00000000 ld .text._Z10function_cv 00000000 .text._Z10function_cv 00000000 ld .text._Z10function_dv 00000000 .text._Z10function_dv 00000000 ld .bss.external_counter 00000000 .bss.external_counter 00000000 ld .comment 00000000 .comment 00000000 ld .ARM.attributes 00000000 .ARM.attributes 00000000 g F .text._Z10function_bv 00000014 _Z10function_bv 00000000 *UND* 00000000 public_function 00000000 g F .text._Z10function_cv 00000002 _Z10function_cv 00000000 g F .text._Z10function_dv 00000002 _Z10function_dv 00000000 g O .bss.external_counter 00000004 external_counter 

अब जब प्रत्येक फ़ंक्शन और ऑब्जेक्ट को स्वतंत्र खंडों में रखा गया है, तो लिंक करने वाला उनसे छुटकारा पा सकता है:

 % rake clean && rake 'show:map[b|c]' SCRIPT=layout2.ld GC=1 SPLIT_SECTIONS=1 arm-none-eabi-gcc -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -ffunction-sections -fdata-sections -mthumb -O2 -mcpu=cortex-m0 -c module_b.cpp -o build/module_b.o arm-none-eabi-gcc -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -ffunction-sections -fdata-sections -mthumb -O2 -mcpu=cortex-m0 -c module_c.cpp -o build/module_c.o arm-none-eabi-ld --gc-sections -T layout2.ld -M -o build/out.elf build/module_b.o build/module_c.o Discarded input sections .text 0x0000000000000000 0x0 build/module_b.o .data 0x0000000000000000 0x0 build/module_b.o .bss 0x0000000000000000 0x0 build/module_b.o .text._Z10function_cv 0x0000000000000000 0x4 build/module_b.o .text._Z10function_dv 0x0000000000000000 0x4 build/module_b.o .text 0x0000000000000000 0x0 build/module_c.o .data 0x0000000000000000 0x0 build/module_c.o .bss 0x0000000000000000 0x0 build/module_c.o ... 

एक निष्कर्ष के बजाय

और फिर, लेख का वॉल्यूम बढ़ रहा है, अब यह पहले भाग के मुकाबले दोगुना है। दुर्भाग्य से, लेआउट एक जटिल विषय है, और "प्रविष्टि" को मास्टर करना मुश्किल है। एक सप्ताह में, हम लिंकर का पता लगाना जारी रखेंगे और अपने एम्बेडेड अनुप्रयोगों के लिए एक पूर्ण निर्मित स्क्रिप्ट बनाएँगे।

PS हमेशा की तरह, टेक्स्ट को प्रूफ करने के लिए बहुत से धन्यवाद।

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