बहुत पहले नहीं, हमने कंपनी में उपयोगकर्ताओं को हमारे सॉफ़्टवेयर में हुई त्रुटियों के बारे में सूचनाएँ भेजने में सक्षम बनाने का निर्णय लिया। जल्दी से नहीं कहा। लेकिन यहाँ समस्या रनटाइम में प्रोग्राम कॉल के वर्तमान स्टैक के बैकट्रेस को प्राप्त करने की थी। यह पता चला कि इस समस्या को हल करने के कई तरीके हैं। यह लेख C / C ++ में लिखे गए प्रोग्रामों के लिए backtracking और Linux और FreeBSD पर चलने के मुद्दे पर मेरे शोध का परिणाम है।

सिद्धांत की बिट

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

void * GetReturnAddress(int depth) {    void *res;    asm (        "mov %1, %%rcx\n"        "MOVE: mov 0x0(%%rbp), %%rax\n"        "loop MOVE\n"       "mov 0x8(%%rax), %rax\n"        "mov %%rax, %0\n" : "=m" (res) : "g" (depth) : "rax", "rcx");    return res; }

फ़ंक्शन को और भी छोटा लिखा जा सकता है, क्योंकि रिटर्न वैल्यू को रक्स रजिस्टर में रखा गया है, आप रेस वेरिएबल के बिना कर सकते हैं।
लेकिन, मेरे लिए व्यक्तिगत रूप से, कोडांतरक आवेषण होना जेडी का सही तरीका नहीं है। तो मैं एक और समाधान की तलाश में चला गया।

Gcc एक्सटेंशन

पहली बात जो आई, वह थी __builtin_return_address फंक्शन कृपया हमें gcc के रचनाकारों द्वारा प्रदान की गई। उसका पूरा विवरण यहाँ प्रस्तुत है:
शून्य * __builtin_return_address (अहस्ताक्षरित int स्तर) - फ़ंक्शन का रिटर्न पता देता है। स्तर = 0 के लिए, फ़ंक्शन वर्तमान फ़ंक्शन के रिटर्न एड्रेस को स्तर = 1 के लिए लौटाएगा, फ़ंक्शन का रिटर्न पता जिसे वर्तमान फ़ंक्शन कहा जाता है, आदि।
इसका उपयोग करते समय, केवल एक चीज है: जब संकलित किया जाता है, तो फ़ंक्शन कोडांतरक कोड की पंक्तियों के एक समूह में प्रकट होता है (आगे हम स्टैक के साथ जाते हैं, अधिक लाइनें) और इसलिए, वे पैरामीटर के रूप में एक चर नहीं ले सकते हैं। इसलिए, एक सुंदर दृश्य रिकॉर्ड के बजाय:
वापसी __builtin_return_address (i);
मुझे बदसूरत लिखना है:

 switch(level) { case 0: return __builtin_return_address(1); case 1: return __builtin_return_address(2); …. }

पहले से बेहतर है। आगे बढ़ो।

पश्व-अनुरेखन

लिनक्स में, मानक पुस्तकालय प्रोग्रामर को कई प्रकार के फ़ंक्शन प्रदान करता है जो हमें आवश्यक जानकारी प्राप्त करने की अनुमति देते हैं। FreeBSD में, इन उद्देश्यों के लिए libexecinfo लाइब्रेरी स्थापित की जानी चाहिए। यहाँ वे हैं:
int बैकट्रेस (शून्य ** बफर, इंट आकार) - एक फ़ंक्शन जो कॉलिंग प्रोग्राम के बैकट्रेस के साथ बफर को भरता है।
char ** backtrace_symbols (शून्य * const * बफर, int आकार) - एक फ़ंक्शन जो पहले फ़ंक्शन का परिणाम लेता है और एक पाठ प्रतिनिधित्व में कार्यों के पते का अनुवाद करता है।
void backtrace_symbols_fd (void * const * बफर, int size, int fd) - पिछले वाले के समान ही करता है, केवल मैलोडॉक के माध्यम से लाइनों के लिए मेमोरी आवंटित करने के बजाय यह सीधे फाइल में जानकारी लिखता है।
कॉल स्टैक पर होने वाले प्रत्येक फ़ंक्शन के लिए, backtrace_symbols एक पंक्ति देता है जो इस तरह दिखता है:

./prog(_Z6myfunci+0x1a) [0x8048840]
जहाँ: प्रॉन बाइनरी का नाम है
_Z6myfunci - कोडित फ़ंक्शन नाम
0x1a - फ़ंक्शन के भीतर ऑफसेट
0x8048840 - फ़ंक्शन पता

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

dladdr

Backtrace_symbols फ़ंक्शन का नुकसान यह है कि यह पाठ के रूप में अपने काम का परिणाम प्रस्तुत करता है। यानी यदि हम कोई जोड़ तोड़ करना चाहते हैं, उदाहरण के लिए, फ़ंक्शन के नाम के साथ, हमें इस पंक्ति को पार्स करना होगा। फिर से जेडी नहीं! यह क्यों जरूरी है यह थोड़ी देर बाद स्पष्ट होगा।
यहाँ डलड्रर फंक्शन बचाव के लिए आता है। दरअसल यह वह है जो अपने भीतर backtrace_symbols कहता है। इसका हस्ताक्षर बहुत सरल है - हम फ़ंक्शन का पता इनपुट को देते हैं, और आउटपुट पर हमें Dl_fofo प्रकार की संरचना मिलती है :
int dladdr (void * addr, Dl_info * जानकारी);
Dladdr कॉल के सफल परिणाम के मामले में, संरचना में backtrace_symbols के मामले में सभी समान डेटा होंगे।
खैर, लगभग ठीक है। अब हमारे पास पते और यहां तक कि फ़ंक्शन नाम भी हैं, यद्यपि इनकोडेड प्रारूप में (हम इस मुद्दे को थोड़ा बाद में हल करने के बारे में बात करेंगे)। आइए देखें कि क्या जानकारी अभी भी बाहर खींची जा सकती है। शायद स्रोत फ़ाइल का नाम और यहां तक कि उस पंक्ति का पता भी जहां फ़ंक्शन स्थित है? दरअसल, भले ही आपको भ्रमित होना पड़े!

इससे क्या लेना-देना!

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

हम हमेशा की तरह डिबग के साथ प्रोग्राम को इकट्ठा करते हैं (-g स्विच या, प्रशंसकों के लिए, -g3 - फिर इनलाइन फ़ंक्शन और सभी प्रकार के मैक्रोज़ को डीबग में शामिल किया जाएगा)।
Objcopy --only-keep-debug a.out a.out.sym चलाएं । अब gdb में आरामदायक काम के लिए आवश्यक सभी जानकारी a.out.sym फ़ाइल में है।
हम स्ट्रिप a.out को निष्पादित करते हैं। यानी डीबग a.out से निकालें।

अब हम कर सकते हैं:

हमारे a.out.sym को ajout के साथ objcopy कमांड --add-gnu-debuglink = a.out.sym a.out के साथ जोड़ें । तब डिबगर स्वचालित रूप से a.out.sym से सभी आवश्यक जानकारी को लोड कर देगा यदि यह उसी फ़ोल्डर में पाता है जिसमें बाइनरी स्थित है।
मैन्युअल रूप से a.out.sym फ़ाइल को gdb से प्रतीक-फ़ाइल a.out.sym कमांड के साथ डाउनलोड करें
अब हमारे पास अपने सॉफ़्टवेयर के लिए डिबगिंग जानकारी एकत्र करने का अवसर है, लेकिन ग्राहक को देने के लिए नहीं। यह करुणा से बाहर किया जा सकता है (डिबग काफी प्रभावशाली राशि है), या सुरक्षा कारणों से (हम हैकर्स के लिए रिवर्स इंजीनियरिंग को जटिल करते हैं)। लेकिन जब आपको क्लाइंट में कुछ सही डिबग करने की आवश्यकता होती है, तो आप बस इसे कई गायब .sym फ़ाइलों के साथ भर सकते हैं।

लेकिन, अगर न केवल लाइन नंबर, बल्कि सोर्स कोड भी देखने की इच्छा है, लेकिन आप इसे क्लाइंट (वाणिज्यिक सॉफ्टवेयर के लिए पूरी तरह से वैध इच्छा) पर अपलोड नहीं करना चाहते हैं, तो आप gdbserver का उपयोग कर सकते हैं, जो आपको दूरस्थ रूप से प्रोग्राम को डीबग करने की अनुमति देता है। ऐसा करने के लिए, आपको चाहिए:

क्लाइंट की तरफ, gdbserver 127.0.0.1:2345 a.out चलाएं
और हमारे भाग के लिए, gdb चलाएं और कमांड लक्ष्य रिमोट को 127.0.0.1:2345 चलाएं। इस स्थिति में, सभी स्रोत फ़ाइलों को उन्हीं रास्तों के साथ सुलभ होना चाहिए जो संकलन के समय उपयोग किए गए थे।

प्रबंध करना / गिराना

अंत में, मैं फ़ंक्शन नाम लिखने के प्रारूप के बारे में कुछ शब्द कहूंगा। संक्षेप में, नामकरण टकराव को हल करने के लिए इस तरह के एक फ़ंक्शन नाम विरूपण लिंकर के लिए आवश्यक है। ठीक है, या आसान भी है, अगर कार्यक्रम में एक ही नाम के साथ दो कार्य हैं लेकिन विभिन्न पैरामीटर (अतिभारित), तो लिंक करने वाले को यह जानने की आवश्यकता है कि किसके साथ काम करना है। इसके लिए, कंपाइलर एक विशेष एल्गोरिथ्म के अनुसार फ़ंक्शन के नाम को एनकोड करता है, इसे एक नया अनूठा नाम बताता है। अंग्रेजी में, इस प्रक्रिया को मैनलिंग कहा जाता है, और रिवर्स डेमोंग्लिंग है ।
एन्कोडेड फ़ंक्शन नाम को मूल स्वरूप में परिवर्तित करने की समस्या को हल करने के लिए, आप फिर से gcc-extension का उपयोग कर सकते हैं:
_{char * abi :: __ cxa_demangle (const char * mangled_name, char * output_buffer, size_t * length, int * status)}
यह फ़ंक्शन, एन्कोडेड फ़ंक्शन नाम और बफर को इनपुट के रूप में लेते हुए आउटपुट पर एक डिकोड किए गए नाम को आउटपुट करता है। इसके उपयोग का एक उदाहरण यहां पाया जा सकता है ।

और अंत में

सही जानकारी प्राप्त करने का सबसे मजेदार तरीका सिर्फ जीडीबी पूछना था। सौभाग्य से, उत्तरार्द्ध हमें ऐसा करने की अनुमति देता है (एक फ़ंक्शन का उदाहरण यहां से लिया गया है )।

 void print_trace() { char pid_buf[30]; sprintf(pid_buf, "%d", getpid()); char name_buf[512]; name_buf[readlink("/proc/self/exe", name_buf, 511)]=0; int child_pid = fork(); if (!child_pid) { dup2(2,1); // redirect output to stderr fprintf(stdout,"stack trace for %s pid=%s\n",name_buf,pid_buf); execlp("gdb", "gdb", "--batch", "-n", "-ex", "thread", "-ex", "bt", name_buf, pid_buf, NULL); abort(); /* If gdb failed to start */ } else { waitpid(child_pid,NULL,0); } }

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

वह सब है।
एक अच्छा डिबगिंग है!

मैं बैकट्रेस के लिए कैसे गया