हम सी को समझते हैं, कोडांतरक सीखना

डेविड अल्बर्ट द्वारा अनूदित - लर्निंग असेंबली द्वारा अंडरस्टैंडिंग सी ।

पिछली बार, एलन ओ'डॉनेल ने जीडीबी का उपयोग करके सी सीखने के तरीके के बारे में बात की थी। आज मैं यह दिखाना चाहता हूं कि GDB का उपयोग कैसे कोडांतरक को समझने में मदद कर सकता है।

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

लेखक का ध्यान दें: इस लेख के सभी कोड मैक ओएस एक्स 10.8.1 के तहत x86_64 प्रोसेसर पर संकलित किए गए थे, जिसमें अनुकूलन अक्षम ( -0 ) के साथ क्लैंग 4.0 का उपयोग किया गया था।

GDB का उपयोग करके असेम्बलर सीखना

आइए GDB का उपयोग करके प्रोग्राम को डिसेबल करके शुरू करें और आउटपुट पढ़ना सीखें। निम्न प्रोग्राम पाठ टाइप करें और इसे एक simple.c फ़ाइल में सहेजें:

int main(void) { int a = 5; int b = a + 6; return 0; } 

अब इसे डिबग मोड में संकलित करें और अनुकूलन अक्षम के साथ और GDB चलाएं।

 $ CFLAGS="-g -O0" make simple cc -g -O0 simple.c -o simple $ gdb simple 

मुख्य फ़ंक्शन पर एक ब्रेकपॉइंट सेट करें और रिटर्न स्टेटमेंट तक पहुंचने तक निष्पादित करना जारी रखें। यह बताने के लिए कि हम इसे दो बार निष्पादित करना चाहते हैं, अगले कथन के बाद नंबर 2 दर्ज करें:

 (gdb) break main (gdb) run (gdb) next 2 

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

 (gdb) disassemble Dump of assembler code for function main: 0x0000000100000f50 <main+0>: push %rbp 0x0000000100000f51 <main+1>: mov %rsp,%rbp 0x0000000100000f54 <main+4>: mov $0x0,%eax 0x0000000100000f59 <main+9>: movl $0x0,-0x4(%rbp) 0x0000000100000f60 <main+16>: movl $0x5,-0x8(%rbp) 0x0000000100000f67 <main+23>: mov -0x8(%rbp),%ecx 0x0000000100000f6a <main+26>: add $0x6,%ecx 0x0000000100000f70 <main+32>: mov %ecx,-0xc(%rbp) 0x0000000100000f73 <main+35>: pop %rbp 0x0000000100000f74 <main+36>: retq End of assembler dump. 

डिफ़ॉल्ट रूप से, असंतुष्ट कमांड AT & T सिंटैक्स में निर्देशों को प्रिंट करता है, जो GNU असेंबलर द्वारा उपयोग किए गए सिंटैक्स से मेल खाता है। सिंटेक्स एटी एंड टी का प्रारूप है: एमनोमोनिक स्रोत , गंतव्य । जहाँ मेनेमिक मानव-पठनीय निर्देश नाम हैं। और स्रोत और गंतव्य ऑपरेंड हैं, जो प्रत्यक्ष मूल्य, रजिस्टर, मेमोरी एड्रेस या लेबल हो सकते हैं। बदले में, तत्काल मूल्य स्थिर होते हैं, उनके पास $ उपसर्ग होता है। उदाहरण के लिए, $ 0x5 हेक्साडेसिमल प्रतिनिधित्व में 5 नंबर से मेल खाती है। % के साथ रजिस्टर नाम उपसर्ग हैं।

रजिस्टरों

यह रजिस्टर का अध्ययन करने के लिए कुछ समय बिताने के लायक है। रजिस्टर डेटा भंडारण स्थान हैं जो सीधे केंद्रीय प्रोसेसर पर स्थित हैं। कुछ अपवादों के साथ, प्रोसेसर रजिस्टरों का आकार या चौड़ाई इसकी वास्तुकला को निर्धारित करती है। इसलिए, यदि आपके पास 64-बिट सीपीयू है, तो इसके रजिस्टरों की चौड़ाई 64 बिट्स होगी। यही बात 32-बिट और 16-बिट प्रोसेसर आदि पर लागू होती है। रजिस्टरों तक पहुंच की गति बहुत अधिक है और यह ठीक इसी वजह से है कि अंकगणित और तार्किक संचालन के संचालन अक्सर उनमें संग्रहीत होते हैं।

प्रोसेसर के x86 परिवार में कई विशेष रजिस्टर और सामान्य प्रयोजन रजिस्टर हैं। सामान्य प्रयोजन रजिस्टरों का उपयोग किसी भी संचालन के लिए किया जा सकता है, और उनमें संग्रहीत डेटा प्रोसेसर के लिए विशेष महत्व नहीं रखता है। दूसरी ओर, प्रोसेसर अपने काम में विशेष रजिस्टरों पर निर्भर करता है, और उनमें संग्रहीत डेटा का विशेष रजिस्टर के आधार पर एक निश्चित मूल्य होता है। हमारे उदाहरण में, % eax और % ecx सामान्य प्रयोजन रजिस्टर हैं, जबकि % rbp और % rsp विशेष रजिस्टर हैं। % Rbp रजिस्टर आधार सूचक है जो वर्तमान स्टैक फ्रेम के आधार को इंगित करता है, और % rsp स्टैक पॉइंटर है जो वर्तमान स्टैक फ्रेम के शीर्ष पर इंगित करता है। % Rbp रजिस्टर हमेशा % rsp से अधिक महत्वपूर्ण होता है, क्योंकि स्टैक हमेशा उच्च मेमोरी पते से शुरू होता है और निचले पते की ओर बढ़ता है। यदि आप "कॉल स्टैक" की अवधारणा से परिचित नहीं हैं, तो आप विकिपीडिया पर एक अच्छी व्याख्या पा सकते हैं।

X86 परिवार प्रोसेसर की ख़ासियत यह है कि वे 8086 16-बिट प्रोसेसर के साथ पूरी तरह से संगत हैं। x86 आर्किटेक्चर के 16-बिट से 32-बिट और अंत में 64-बिट में बदलने के दौरान, रजिस्टरों का विस्तार किया गया और नए नाम प्राप्त किए, कोड के साथ संगतता बनाए रखने के लिए जो पहले प्रोसेसर के लिए लिखा गया था।

सामान्य-उद्देश्य रजिस्टर AX लें, जो 16 बिट्स चौड़ा है। एएच नाम से इसकी उच्च बाइट तक पहुंच होती है, और निम्न बाइट के लिए - एएल नाम से। जब 32-बिट 80386 दिखाई दिया, तो विस्तारित (एक्सटेंडेड) AX या EAX 32-बिट रजिस्टर बन गया, जबकि AX 16-बिट बना रहा और EAX रजिस्टर का सबसे छोटा आधा हिस्सा बन गया। इसी तरह, जब x86_64 दिखाई दिया, तो "R" उपसर्ग का उपयोग किया गया और EAX 64-बिट नक्स रजिस्टर का सबसे छोटा आधा बन गया। उपरोक्त रिश्तों को स्पष्ट करने के लिए विकिपीडिया लेख पर आधारित एक चित्र निम्नलिखित है:

 |__64__|__56__|__48__|__40__|__32__|__24__|__16__|__8___| |__________________________RAX__________________________| |xxxxxxxxxxxxxxxxxxxxxxxxxxx|____________EAX____________| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|_____AX______| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|__AH__|__AL__| 

कोड पर वापस जाएं

यह पहले से ही हमारे असंतुष्ट कार्यक्रम को पार्स करने के लिए पर्याप्त होना चाहिए:

 0x0000000100000f50 <main+0>: push %rbp 0x0000000100000f51 <main+1>: mov %rsp,%rbp 

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

 0x0000000100000f54 <main+4>: mov $0x0,%eax 

यह निर्देश 0 %% पर कॉपी करता है। X86 आर्किटेक्चर कॉलिंग कन्वेंशन का कहना है कि फ़ंक्शन द्वारा लौटाए गए मान % eax रजिस्टर में संग्रहीत किए गए हैं, इसलिए उपरोक्त कथन हमें हमारे फ़ंक्शन के अंत में 0 वापस करने के लिए कहता है।

 0x0000000100000f59 <main+9>: movl $0x0,-0x4(%rbp) 

यहां हमारे पास कुछ ऐसा है जो हमें पहले नहीं मिला है: -0x4 (% आरबीपी) । कोष्ठक हमें बताएं कि यह एक स्मृति पता है। इस खंड में, % rbp , तथाकथित आधार रजिस्टर, और -0x4 , जो ऑफसेट है। यह % rbp + -0x4 लिखने के बराबर है। जैसा कि स्टैक नीचे बढ़ता है, बेस स्टैक फ्रेम से 4 घटाना हमें वर्तमान फ्रेम में ले जाता है, जहां स्थानीय चर संग्रहित होता है। इसका मतलब है कि यह निर्देश 0 % rbp - 4 पते पर संग्रहीत करता है। मुझे यह पता लगाने में थोड़ा समय लगा कि यह रेखा किस लिए है, और यह मुझे प्रतीत होता है कि क्लैंग मुख्य फ़ंक्शन से अनुमानित रूप से लौटाए गए मान के लिए एक छिपे हुए स्थानीय चर को आवंटित करता है।

आप यह भी देख सकते हैं कि मेनेमोनिक में प्रत्यय एल है । इसका मतलब है कि ऑपरेंड एल ओन्ग (पूर्णांक के लिए 32 बिट्स) का होगा। अन्य संभावित प्रत्यय b yte , s hort , w ord , q uad और t en हैं । यदि आपके पास कोई ऐसा निर्देश आता है जिसमें कोई प्रत्यय नहीं है, तो इस तरह के निर्देश का आकार स्रोत रजिस्टर या गंतव्य रजिस्टर के आकार से निहित होगा। उदाहरण के लिए, पिछली पंक्ति में, % eax 32 बिट चौड़ा है, इसलिए वास्तविक अनुदेश वास्तव में movl है ।

 0x0000000100000f60 <main+16>: movl $0x5,-0x8(%rbp) 

अब हम अपने परीक्षण कार्यक्रम के मूल में जा रहे हैं। असेंबलर लाइन मुख्य फ़ंक्शन में पहली सी लाइन है, और यह अगले उपलब्ध स्थानीय चर स्लॉट ( % rbp - 0x8 ) में 5 नंबर रखती है , हमारे पिछले स्थानीय चर के नीचे 4 बाइट्स। यह चर का स्थान है । इसे सत्यापित करने के लिए हम GDB का उपयोग कर सकते हैं:

 (gdb) x &a 0x7fff5fbff768: 0x00000005 (gdb) x $rbp - 8 0x7fff5fbff768: 0x00000005 

ध्यान दें कि मेमोरी एड्रेस एक ही है। आप यह भी नोट कर सकते हैं कि GDB हमारे रजिस्टरों के लिए चर सेट करता है, इसलिए, GDB में सभी चर की तरह, उनका नाम $ के साथ उपसर्ग है, जबकि AT & T से कोडांतरक में % उपसर्ग का उपयोग किया जाता है।

 0x0000000100000f67 <main+23>: mov -0x8(%rbp),%ecx 0x0000000100000f6a <main+26>: add $0x6,%ecx 0x0000000100000f70 <main+32>: mov %ecx,-0xc(%rbp) 

इसके बाद, हम चर को एक % ecx में डालते हैं, हमारे सामान्य-उद्देश्य रजिस्टर में से एक, इसमें 6 नंबर जोड़ते हैं और परिणाम को % rbp - 0xc में सहेजते हैं । यह मुख्य कार्य की दूसरी पंक्ति है। आपने पहले ही अनुमान लगा लिया होगा कि पता % rbp - 0xc मैच वेरिएबल b है , जिसे हम GDB के साथ भी देख सकते हैं:

 (gdb) x &b 0x7fff5fbff764: 0x0000000b (gdb) x $rbp - 0xc 0x7fff5fbff764: 0x0000000b 

बाकी मुख्य कार्य सिर्फ एक सफाई प्रक्रिया है, जिसे उपसंहार भी कहा जाता है।

 0x0000000100000f73 <main+35>: pop %rbp 0x0000000100000f74 <main+36>: retq 

हम पुराने बेस पॉइंटर को निकालते हैं और इसे वापस % rbp में डालते हैं , और फिर रिटेक इंस्ट्रक्शन हमें रिटर्न एड्रेस पर फेंक देगा , जो स्टैक फ्रेम में भी संग्रहीत है।

उस क्षण तक, हमने एक छोटे सी कार्यक्रम को अलग करने के लिए GDB का उपयोग किया, एटी एंड टी से कोडांतरक सिंटैक्स को पढ़ने के माध्यम से चला गया, और रजिस्टरों और मेमोरी एड्रेस के ऑपरेंड के विषय का पता लगाया। हमने % rbp के मुकाबले स्थानीय चर के भंडारण स्थान की जांच करने के लिए GDB का उपयोग किया। अब हम स्थैतिक स्थानीय चरों के कार्य सिद्धांतों को समझाने के लिए अधिग्रहीत ज्ञान का उपयोग करते हैं।

स्थैतिक स्थानीय चर को समझना

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

 /* static.c */ #include <stdio.h> int natural_generator() { int a = 1; static int b = -1; b += 1; return a + b; } int main() { printf("%d\n", natural_generator()); printf("%d\n", natural_generator()); printf("%d\n", natural_generator()); return 0; } 

जब आप इस प्रोग्राम को संकलित करते हैं और चलाते हैं, तो यह पहले तीन प्राकृतिक संख्याओं का उत्पादन करेगा:

 $ CFLAGS="-g -O0" make static cc -g -O0 static.c -o static $ ./static 1 2 3 

लेकिन यह कैसे काम करता है? यह जानने के लिए, चलो GDB पर जाएं और कोडांतरक कोड देखें। मैंने पता की जानकारी को हटा दिया है जो GDB डिस्सेम्बलर आउटपुट में जोड़ता है और अब स्क्रीन पर सब कुछ फिट बैठता है:

 $ gdb static (gdb) break natural_generator (gdb) run (gdb) disassemble Dump of assembler code for function natural_generator: push %rbp mov %rsp,%rbp movl $0x1,-0x4(%rbp) mov 0x177(%rip),%eax # 0x100001018 <natural_generator.b> add $0x1,%eax mov %eax,0x16c(%rip) # 0x100001018 <natural_generator.b> mov -0x4(%rbp),%eax add 0x163(%rip),%eax # 0x100001018 <natural_generator.b> pop %rbp retq End of assembler dump. 

पहली चीज़ जो हमें करने की ज़रूरत है, वह यह पता लगाना है कि वर्तमान में हम क्या निर्देश दे रहे हैं। हम निर्देश सूचक या टीम काउंटर की जांच करके ऐसा कर सकते हैं। एक निर्देश सूचक एक रजिस्टर है जो अगले निर्देश का पता संग्रहीत करता है। X86_64 आर्किटेक्चर में, इस रजिस्टर को % रिप कहा जाता है। हम $ रिप चर का उपयोग करके अनुदेश सूचक तक पहुंच सकते हैं, या, एक विकल्प के रूप में, हम वास्तुशिल्प रूप से स्वतंत्र $ पीसी चर का उपयोग कर सकते हैं:

 (gdb) x/i $pc 0x100000e94 <natural_generator+4>: movl $0x1,-0x4(%rbp) 

निर्देश सूचक में विशेष रूप से निष्पादित करने के लिए अगले निर्देश के लिए एक सूचक होता है, जिसका अर्थ है कि तीसरा निर्देश अभी तक निष्पादित नहीं किया गया है, लेकिन होने वाला है।

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

 (gdb) display/i $pc 1: x/i $pc 0x100000e94 <natural_generator+4>: movl $0x1,-0x4(%rbp) 

GDB अब आउटपुट से पहले हमेशा अगला विवरण दिखाने के लिए कॉन्फ़िगर किया गया है।

हम पहले से ही उस फ़ंक्शन के प्रस्ताव के माध्यम से चले गए, जिसे हमने पहले जांचा था, इसलिए हम तीसरे निर्देश के साथ तुरंत शुरू करेंगे। यह कोड की पहली पंक्ति से मेल खाती है, जो कि चर 1 को असाइन करती है । अगले आदेश के बजाय, जो कोड की अगली पंक्ति में जाता है, हम नेई का उपयोग करेंगे , जो अगले कोडांतरक निर्देश पर जाता है। अब आइए परिकल्पना का परीक्षण करने के लिए पता % rbp - 0x4 की जाँच करें कि चर यहाँ संग्रहीत है:

 (gdb) nexti 7 b += 1; 1: x/i $pc mov 0x177(%rip),%eax # 0x100001018 <natural_generator.b> (gdb) x $rbp - 0x4 0x7fff5fbff78c: 0x00000001 (gdb) x &a 0x7fff5fbff78c: 0x00000001 

और हम देखते हैं कि पते वही हैं, जैसा कि हमें उम्मीद थी। निम्नलिखित निर्देश अधिक दिलचस्प है:

 mov 0x177(%rip),%eax # 0x100001018 <natural_generator.b> 

यहाँ हम लाइन निर्देश स्थिर int b = -1 के निष्पादन को देखने की उम्मीद करते हैं ; , लेकिन यह पहले की तुलना में काफी अलग दिखता है। एक तरफ, स्टैक फ्रेम का कोई संदर्भ नहीं है, जहां हमें स्थानीय चर देखने की उम्मीद थी। -0x1 भी नहीं! इसके स्थान पर, हमारे पास एक निर्देश है जो 0x100001018 पते से कुछ लोड करता है, जो निर्देश सूचक के बाद कहीं स्थित है, % ex रजिस्टर में। GDB हमें मेमोरी ऑपरेंड की गणना के परिणाम के साथ एक उपयोगी टिप्पणी देता है, जो बताता है कि natural_generator.b इस पते पर स्थित है। आइए निर्देशों का पालन करें और देखें कि क्या होता है:

 (gdb) nexti (gdb) p $rax $3 = 4294967295 (gdb) p/x $rax $5 = 0xffffffff 

इस तथ्य के बावजूद कि डिस्सेम्बलर रिसीवर के रूप में % ईएक्सएक्स रजिस्टर दिखाता है, हम $ rax प्रिंट करते हैं , क्योंकि GDB रजिस्टर की पूरी चौड़ाई के लिए चर सेट करता है।

इस स्थिति में, हमें यह याद रखना चाहिए कि चर के प्रकार ऐसे होते हैं जो यह निर्धारित करते हैं कि वे हस्ताक्षरित हैं या अहस्ताक्षरित हैं, इस प्रकार के रजिस्टर नहीं करते हैं, इसलिए GDB % rax रजिस्टर के मान को बिना बताए प्रदर्शित करता है। चलो फिर से कोशिश करते हैं, एक हस्ताक्षरित पूर्णांक के लिए % rax मान परिवर्तित करते हुए :

 (gdb) p (int)$rax $11 = -1 

लगता है जैसे हमने बी पाया। हम x कमांड का उपयोग करके इसे फिर से सत्यापित कर सकते हैं:

 (gdb) x/d 0x100001018 0x100001018 <natural_generator.b>: -1 (gdb) x/d &b 0x100001018 <natural_generator.b>: -1 

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

इस दृष्टिकोण के साथ, चीजें समझ में आने लगती हैं। B को % ex में सहेजने के बाद, हम कोड की अगली पंक्ति पर चलते हैं, जहाँ हम b बढ़ाते हैं। यह निम्नलिखित निर्देशों का अनुपालन करता है:

 add $0x1,%eax mov %eax,0x16c(%rip) # 0x100001018 <natural_generator.b> 

यहां हम 1 %% ईएक्स जोड़ते हैं और परिणाम को मेमोरी में वापस लिखते हैं। आइए इन निर्देशों का पालन करें और परिणाम देखें:

 (gdb) nexti 2 (gdb) x/d &b 0x100001018 <natural_generator.b>: 0 (gdb) p (int)$rax $15 = 0 

निम्नलिखित दो निर्देश परिणाम a + b वापस करने के लिए जिम्मेदार हैं:

 mov -0x4(%rbp),%eax add 0x163(%rip),%eax # 0x100001018 <natural_generator.b> 

यहाँ हम चर को % ex में लोड करते हैं, और फिर b को जोड़ते हैं। इस बिंदु पर, हम मूल्य को संग्रहीत करने के लिए% eax की अपेक्षा करते हैं। 1. आइए देखें:

 (gdb) nexti 2 (gdb) p $rax $16 = 1 

% Eax रजिस्टर का उपयोग natural_generator फ़ंक्शन द्वारा दिए गए मान को संग्रहीत करने के लिए किया जाता है, और हम एक उपसंहार की अपेक्षा करते हैं जो स्टैक को साफ़ करेगा और परिणाम देगा:

 pop %rbp retq 

हमने पता लगाया कि वेरिएबल b को कैसे इनिशियलाइज़ किया जाता है। अब देखते हैं कि क्या होता है जब natural_generator फ़ंक्शन को बार-बार कहा जाता है:

 (gdb) continue Continuing. 1 Breakpoint 1, natural_generator () at static.c:5 5 int a = 1; 1: x/i $pc 0x100000e94 <natural_generator+4>: movl $0x1,-0x4(%rbp) (gdb) x &b 0x100001018 <natural_generator.b>: 0 

चूँकि चर b को शेष चर के साथ स्टैक पर संग्रहीत नहीं किया गया है, यह अभी भी 0 है जब natural_generator को फिर से कहा जाता है। इससे कोई फर्क नहीं पड़ता कि हमारे जनरेटर को कितनी बार बुलाया जाएगा, चर b हमेशा अपना पिछला मान रखेगा। यह सब इसलिए है क्योंकि इसे स्टैक से संग्रहीत किया जाता है और प्रारंभ किया जाता है जब लोडर प्रोग्राम को मेमोरी में डालता है, और हमारे किसी भी मशीन कोड के अनुसार नहीं।

निष्कर्ष

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

अनुवादक से: निम्न स्तर की प्रोग्रामिंग मेरी प्रोफ़ाइल नहीं है, इसलिए यदि मैंने कोई अशुद्धियाँ की हैं, तो मुझे लैन में उनके बारे में जानकर खुशी होगी।