🕵🏾 🤛🏿 ❇️ एआरएम पर स्टैक ट्रेस कैसे काम करता है 🏮 🌕 🐆

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

आइए लिनक्स कर्नेल में दो मुख्य स्टैक ट्रेस विधियों को देखें।

फ्रेम के माध्यम से खोलना खोलना

आइए एक सरल दृष्टिकोण से शुरू करें जो लिनक्स कर्नेल में पाया जा सकता है, लेकिन जो वर्तमान में जीसीसी में पदावनत स्थिति है।

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

लिंक रजिस्टर (LR) रजिस्टर R14 है। यह उप-सूचना, फ़ंक्शन कॉल और अपवादों के लिए वापसी जानकारी संग्रहीत करता है। रीसेट करने पर, प्रोसेसर LR मान को 0xFFFFFFFF पर सेट करता है

अगला, हमें स्टैक से ऊपर जाने और स्टैक से एलआर रजिस्टरों के नए मूल्यों को लोड करने की आवश्यकता है। संकलक के लिए स्टैक फ्रेम की संरचना निम्नानुसार है:

/* The stack backtrace structure is as follows: fp points to here: | save code pointer | [fp] | return link value | [fp, #-4] | return sp value | [fp, #-8] | return fp value | [fp, #-12] [| saved r10 value |] [| saved r9 value |] [| saved r8 value |] ... [| saved r0 value |] r0-r3 are not normally saved in a C function. */

यह विवरण GCC हेडर फ़ाइल gcc / gcc / config / arm / arm.h से लिया गया है।

यानी संकलक (हमारे मामले में जीसीसी) को किसी तरह सूचित किया जा सकता है कि हम स्टैक ट्रेस करना चाहते हैं। और फिर प्रत्येक फ़ंक्शन के प्रस्ताव में कंपाइलर किसी प्रकार की सहायक संरचना तैयार करेगा। आप देख सकते हैं कि इस संरचना में LR रजिस्टर का "अगला" मूल्य है जो हमें चाहिए, और, सबसे महत्वपूर्ण बात, इसमें अगले फ्रेम का पता है | return fp value | [fp, #-12] | return fp value | [fp, #-12]

यह संकलक मोड -mapcs- फ्रेम विकल्प द्वारा निर्दिष्ट किया गया है। विकल्प के विवरण में एक उल्लेख है "निर्दिष्ट -fomit- फ़्रेम-पॉइंटर इस विकल्प के साथ स्टैक फ़्रेम पत्ती कार्यों के लिए उत्पन्न नहीं होने का कारण बनता है।" यहां, पत्ती फ़ंक्शन का मतलब उन लोगों से समझा जाता है जो अन्य कार्यों के लिए कोई कॉल नहीं करते हैं, इसलिए उन्हें थोड़ा आसान बनाया जा सकता है।

आपको यह भी आश्चर्य हो सकता है कि इस मामले में कोडांतरक कार्यों के साथ क्या करना है। वास्तव में, कुछ भी मुश्किल नहीं है - आपको विशेष मैक्रोज़ सम्मिलित करने की आवश्यकता है। लिनक्स कर्नेल में उपकरण / objtool / डॉक्यूमेंटेशन / स्टैक-वैलिडेशन.टेक्स्ट फ़ाइल से:

प्रत्येक कॉल करने योग्य फ़ंक्शन को ELF के साथ एनोटेट किया जाना चाहिए
फ़ंक्शन प्रकार। Asm कोड में, यह आमतौर पर का उपयोग करके किया जाता है
ENTRY / ENDPROC मैक्रोज़।

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

लिनक्स कर्नेल से स्टैक को हटाने का कार्य निम्नलिखित है:

 #if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) int notrace unwind_frame(struct stackframe *frame) { unsigned long high, low; unsigned long fp = frame->fp; /*    ,    */ /* restore the registers from the stack frame */ frame->fp = *(unsigned long *)(fp - 12); frame->sp = *(unsigned long *)(fp - 8); frame->pc = *(unsigned long *)(fp - 4); return 0; } #endif

लेकिन यहां मैं defined(CONFIG_ARM_UNWIND) साथ लाइन को चिह्नित करना चाहता हूं। वह संकेत देती है कि लिनक्स कर्नेल भी एक और कार्यान्वयन का उपयोग करता है shr_frame, और हम इसके बारे में थोड़ी देर बाद बात करेंगे।

एआरएम अनुदेश सेट के लिए -मैप-फ्रेम विकल्प केवल मान्य है। लेकिन यह ज्ञात है कि एआरएम माइक्रोकंट्रोलर्स के पास निर्देशों का एक और सेट है - थम्ब (थम्ब -1 और थम्ब -2, अधिक सटीक होने के लिए), इसका उपयोग मुख्य रूप से कॉर्टेक्स-एम श्रृंखला के लिए किया जाता है। थंब मोड के लिए फ़्रेम जनरेशन को सक्षम करने के लिए, -mtpcs-फ़्रेम और -mtpcs- लीफ़-फ़्रेम फ़्लैग का उपयोग करें । संक्षेप में, यह -मैप्स-फ्रेम का एक एनालॉग है। दिलचस्प बात यह है कि ये विकल्प वर्तमान में केवल Cortex-M0 / M1 के लिए काम करते हैं। कुछ समय तक मैं यह पता नहीं लगा पाया कि मैं कॉर्टेक्स-एम 3 / एम 4 / ... के लिए वांछित छवि क्यों संकलित नहीं कर सका। जब मैंने एआरएम के लिए सभी जीसीसी विकल्पों को फिर से पढ़ा और इंटरनेट पर खोज की, तो मुझे एहसास हुआ कि यह शायद एक बग था। इसलिए, मैं सीधे हाथ-कोई-ईबी-जीसीसी संकलक के स्रोत कोड में चढ़ गया। संकलक ने ARM, Thumb-1 और Thumb-2 के लिए फ्रेम कैसे तैयार किया, इसका अध्ययन करने के बाद, मैं इस निष्कर्ष पर पहुंचा कि उन्होंने Thumb-2 को बायपास किया, यानी फिलहाल फ्रेम केवल Thumb-1 और ARM के लिए ही उत्पन्न होता है। बग बनाने के बाद, जीसीसी डेवलपर्स ने समझाया कि एआरएम के लिए मानक पहले ही कई बार बदल चुके हैं और ये झंडे बहुत पुराने हैं, लेकिन किसी कारण से वे सभी अभी भी संकलक में मौजूद हैं। नीचे फ़ंक्शन का डिस्सेम्बलर है जिसके लिए फ्रेम उत्पन्न होता है।

 static int my_func(int a) { my_func2(7); return 0; }

 00008134 <my_func>: 8134: b084 sub sp, #16 8136: b580 push {r7, lr} 8138: aa06 add r2, sp, #24 813a: 9203 str r2, [sp, #12] 813c: 467a mov r2, pc 813e: 9205 str r2, [sp, #20] 8140: 465a mov r2, fp 8142: 9202 str r2, [sp, #8] 8144: 4672 mov r2, lr 8146: 9204 str r2, [sp, #16] 8148: aa05 add r2, sp, #20 814a: 4693 mov fp, r2 814c: b082 sub sp, #8 814e: af00 add r7, sp, #0

तुलना में, एआरएम निर्देशों के लिए एक ही फ़ंक्शन का डिस्सेम्बलर

 000081f8 <my_func>: 81f8: e1a0c00d mov ip, sp 81fc: e92dd800 push {fp, ip, lr, pc} 8200: e24cb004 sub fp, ip, #4 8204: e24dd008 sub sp, sp, #8

पहली नज़र में, ऐसा लग सकता है कि ये पूरी तरह से अलग चीजें हैं। लेकिन वास्तव में, फ्रेम बिल्कुल समान हैं, तथ्य यह है कि थम्ब मोड में, पुश निर्देश केवल कम रजिस्टरों (r0 - r7) और lr रजिस्टर को ढेर करने की अनुमति देता है। अन्य सभी रजिस्टरों के लिए, यह दो चरणों में निर्देश के माध्यम से किया जाता है mov और str, जैसा कि ऊपर दिए गए उदाहरण में है।

अपवाद के माध्यम से ढेर खोलना

एआरएम आर्किटेक्चर ( EHABI ) मानक के लिए अपवाद हैंडलिंग ABI के आधार पर एक वैकल्पिक दृष्टिकोण स्टैक अनइंडिंग है । वास्तव में, इस मानक का उपयोग करने का मुख्य उदाहरण सी ++ जैसी भाषाओं में अपवाद हैंडलिंग है। स्टैक को ट्रेस करने के लिए कंपाइलर द्वारा तैयार अपवाद हैंडलिंग के लिए भी जानकारी का उपयोग किया जा सकता है। यह मोड विकल्प GCC -fexception (या -funwind- फ्रेम ) के साथ सक्षम है।

आइए देखें कि यह कैसे किया जाता है। इसके साथ शुरू करने के लिए, यह दस्तावेज़ (EHABI) सहायक तालिकाओं को बनाने के लिए कुछ आवश्यकताओं को लागू करता है .ARM.ididx और .ARM.extab। यह इस तरह से है .ARM.exidx अनुभाग लिनक्स कर्नेल स्रोतों में परिभाषित किया गया है। फ़ाइल आर्क / आर्म / कर्नेल / vmlinux.lds.h से :

 /* Stack unwinding tables */ #define ARM_UNWIND_SECTIONS \ . = ALIGN(8); \ .ARM.unwind_idx : { \ __start_unwind_idx = .; \ *(.ARM.exidx*) \ __stop_unwind_idx = .; \ } \

एआरएम आर्किटेक्चर के लिए "अपवाद हैंडलिंग एबीआई" मानक निम्नलिखित विधि के रूप में .ARM.exidx तालिका के प्रत्येक तत्व को परिभाषित करता है:

 struct unwind_idx { unsigned long addr_offset; unsigned long insn; };

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

ये निर्देश पहले से उल्लेखित EHABI मानक में वर्णित हैं:

इसके अलावा, लिनक्स पर इस दुभाषिया का मुख्य कार्यान्वयन फ़ाइल आर्क / आर्म / कर्नेल / खोल में है

लेन्डरफ्रेम फंक्शन का कार्यान्वयन

 int unwind_frame(struct stackframe *frame) { unsigned long low; const struct unwind_idx *idx; struct unwind_ctrl_block ctrl; /*   ,   */ /*   ARM.exidx    ,   PC */ idx = unwind_find_idx(frame->pc); if (!idx) { pr_warn("unwind: Index not found %08lx\n", frame->pc); return -URC_FAILURE; } ctrl.vrs[FP] = frame->fp; ctrl.vrs[SP] = frame->sp; ctrl.vrs[LR] = frame->lr; ctrl.vrs[PC] = 0; if (idx->insn == 1) /* can't unwind */ return -URC_FAILURE; else if ((idx->insn & 0x80000000) == 0) /* prel31 to the unwind table */ ctrl.insn = (unsigned long *)prel31_to_addr(&idx->insn); else if ((idx->insn & 0xff000000) == 0x80000000) /* only personality routine 0 supported in the index */ ctrl.insn = &idx->insn; else { pr_warn("unwind: Unsupported personality routine %08lx in the index at %p\n", idx->insn, idx); return -URC_FAILURE; } /*       ,    - * ,       */ /* check the personality routine */ if ((*ctrl.insn & 0xff000000) == 0x80000000) { ctrl.byte = 2; ctrl.entries = 1; } else if ((*ctrl.insn & 0xff000000) == 0x81000000) { ctrl.byte = 1; ctrl.entries = 1 + ((*ctrl.insn & 0x00ff0000) >> 16); } else { pr_warn("unwind: Unsupported personality routine %08lx at %p\n", *ctrl.insn, ctrl.insn); return -URC_FAILURE; } ctrl.check_each_pop = 0; /* ,      */ while (ctrl.entries > 0) { int urc; if ((ctrl.sp_high - ctrl.vrs[SP]) < sizeof(ctrl.vrs)) ctrl.check_each_pop = 1; urc = unwind_exec_insn(&ctrl); if (urc < 0) return urc; if (ctrl.vrs[SP] < low || ctrl.vrs[SP] >= ctrl.sp_high) return -URC_FAILURE; } /*   */ /* ,       */ frame->fp = ctrl.vrs[FP]; frame->sp = ctrl.vrs[SP]; frame->lr = ctrl.vrs[LR]; frame->pc = ctrl.vrs[PC]; return URC_OK; }

यह खोल_फ्रेम फ़ंक्शन का कार्यान्वयन है, जिसका उपयोग CONFIG_ARM_UNWIND विकल्प सक्षम होने पर किया जाता है। मैंने रूसी में स्पष्टीकरण के साथ टिप्पणियों को सीधे स्रोत पाठ में डाला।

निम्न का एक उदाहरण है कि कैसे .ARM.exidx तालिका तत्व Embox में कर्नेल_स्टार्ट फ़ंक्शन के लिए दिखता है:

 $ arm-none-eabi-readelf -u build/base/bin/embox Unwind table index '.ARM.exidx' at offset 0xaa6d4 contains 2806 entries: <...> 0x1c3c <kernel_start>: @0xafe40 Compact model index: 1 0x9b vsp = r11 0x40 vsp = vsp - 4 0x84 0x80 pop {r11, r14} 0xb0 finish 0xb0 finish <...>

और यहाँ उसके disassembler है:

 00001c3c <kernel_start>: void kernel_start(void) { 1c3c: e92d4800 push {fp, lr} 1c40: e28db004 add fp, sp, #4 <...>

चलो चरणों के माध्यम से चलते हैं। हम असाइनमेंट vps = r11 देखते हैं। (आर 11 यह एफपी है) और फिर vps = vps - 4 । यह add fp, sp, #4 निर्देश से मेल खाता है। अगला पॉप {r11, r14} आता है, जो push {fp, lr} निर्देश से मेल खाता है। अंतिम finish निर्देश निष्पादन के अंत की रिपोर्ट करता है (ईमानदार होने के लिए, मुझे अभी भी समझ में नहीं आया कि वहां दो फिनिश निर्देश क्यों हैं)।

अब देखते हैं कि -फंडविंड-फ्रेम फ्लैग ईट के साथ असेंबली कितनी मेमोरी बनाती है।
प्रयोग के लिए, मैंने STM32F4-Discovery मंच के लिए Embox संकलित किया। यहाँ objdump परिणाम हैं:

-फंडविंड-फ्रेम ध्वज के साथ:

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0005a600 08000000 08000000 00004000 2**14
CONTENTS, ALLOC, LOAD, CODE
1 .ARM.exidx 00003fd8 0805a600 0805a600 0005e600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .ARM.extab 000049d0 0805e5d8 0805e5d8 000625d8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .rodata 0003e380 08062fc0 08062fc0 00066fc0 2**5

बिना झंडे के:

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00058b1c 08000000 08000000 00004000 2**14
CONTENTS, ALLOC, LOAD, CODE
1 .ARM.exidx 00000008 08058b1c 08058b1c 0005cb1c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .rodata 0003e380 08058b40 08058b40 0005cb40 2**5

यह गणना करना आसान है कि .ARM.exidx और .ARM.extab खंड लगभग 1/10 भाग के आकार के हैं। उसके बाद, मैंने ARM9 के आधार पर ARM इंटीग्रेटर CP के लिए - एक बड़ी छवि एकत्र की और वहां ये अनुभाग .text अनुभाग के आकार का 1/12 था। लेकिन यह स्पष्ट है कि यह अनुपात परियोजना से परियोजना में भिन्न हो सकता है। यह भी पता चला है कि -macps-फ़्रेम फ़्लैग जोड़ने वाली छवि का आकार अपवाद विकल्प (जो अपेक्षित है) से छोटा है। इसलिए, उदाहरण के लिए, जब .text सेक्शन का आकार 600 Kb था, तो .ARM.exidx + .ARM.extab का कुल आकार 50 Kb था, और -मैप-फ्रेम ध्वज के साथ अतिरिक्त कोड का आकार केवल 10 Kb था। लेकिन अगर हम ऊपर देखते हैं, तो कोर्टेक्स-एम 1 (याद रखें, mov / स्टैक के माध्यम से) के लिए एक बड़ा प्रस्तावना उत्पन्न किया गया था, तो यह स्पष्ट हो जाता है कि इस मामले में व्यावहारिक रूप से कोई अंतर नहीं होगा, जिसका अर्थ है कि यह थम्ब मोड के लिए -mt पीसी-फ्रेम का उपयोग करने की संभावना नहीं है। कम से कम कुछ समझ में आता है।

क्या अब एआरएम के लिए ऐसे स्टैक ट्रेस की जरूरत है? विकल्प क्या हैं?

एक तीसरा दृष्टिकोण डिबगर का उपयोग करके स्टैक का पता लगाने के लिए है। ऐसा लगता है कि FreeRTOS के साथ काम करने के लिए कई ऑपरेटिंग सिस्टम, NuttX माइक्रोकंट्रोलर वर्तमान में इस विशेष अनुरेखण विकल्प का सुझाव देते हैं या एक डिस्सेम्बलर देखने की पेशकश करते हैं।

नतीजतन, हम इस निष्कर्ष पर पहुंचे कि रन टाइम में हथियारों के लिए स्टैक ट्रेस वास्तव में कहीं भी उपयोग नहीं किया जाता है। यह संभवतः काम करते समय सबसे कुशल कोड बनाने की इच्छा का परिणाम है, और डिबगिंग कार्रवाइयों (जिसमें स्टैक का प्रचार शामिल है) को ऑफ़लाइन निकालना। दूसरी ओर, यदि ओएस पहले से ही C ++ कोड का उपयोग करता है, तो यह .ARM.exvillx के ट्रेसिंग के कार्यान्वयन का उपयोग करना काफी संभव है।

अच्छी तरह से और हाँ, Embox में रुकावट में गलत स्टैक आउटपुट के साथ समस्या को बहुत सरल रूप से हल किया गया था, यह स्टैक पर एलआर रजिस्टर को बचाने के लिए पर्याप्त निकला।

एआरएम पर स्टैक ट्रेस कैसे काम करता है

फ्रेम के माध्यम से खोलना खोलना

अपवाद के माध्यम से ढेर खोलना

क्या अब एआरएम के लिए ऐसे स्टैक ट्रेस की जरूरत है? विकल्प क्या हैं?

More articles: