debugging - एक डीबगर कैसे काम करता है?




internals (4)

मैं सोच रहा हूं कि एक डीबगर कैसे काम करता है? पहले से ही निष्पादन योग्य चलाने के लिए 'संलग्न' किया जा सकता है। मैं समझता हूं कि कंपाइलर कोड को मशीन भाषा में अनुवाद करता है, लेकिन फिर डीबगर को 'पता' कैसे लगाया जा रहा है?


जैसा मुझे समझ में आया:

X86 पर सॉफ़्टवेयर ब्रेकपॉइंट्स के लिए, डीबगर CC ( int3 ) के साथ निर्देश के पहले बाइट को प्रतिस्थापित करता है। यह विंडोज पर WriteProcessMemory साथ किया जाता है। जब सीपीयू उस निर्देश को int3 करता है, और int3 निष्पादित करता है, तो यह CPU को डीबग अपवाद उत्पन्न करने का कारण बनता है। ओएस को इस बाधा को प्राप्त होता है, यह समझता है कि प्रक्रिया को डीबग किया जा रहा है, और ब्रेकपॉइंट मारा गया डीबगर प्रक्रिया को सूचित करता है।

ब्रेकपॉइंट हिट होने के बाद और प्रक्रिया बंद हो जाती है, डीबगर ब्रेकपॉइंट्स की अपनी सूची में दिखता है, और CC को मूल रूप से बाइट के साथ बदल देता है। डीबगर TF सेट करता है , EFLAGS में ट्रैप फ्लैग ( CONTEXT को संशोधित करके), और प्रक्रिया जारी रखता है। ट्रैप ध्वज सीपीयू को अगले निर्देश पर स्वचालित रूप से एक-चरण अपवाद ( INT 1 ) उत्पन्न करने का कारण बनता है।

जब अगली बार डीबग की प्रक्रिया बंद हो जाती है, तो डीबगर फिर से CC साथ ब्रेकपॉइंट निर्देश के पहले बाइट को बदल देता है, और प्रक्रिया जारी है।

मुझे यकीन नहीं है कि यह वास्तव में सभी डिबगर्स द्वारा कार्यान्वित किया गया है, लेकिन मैंने एक Win32 प्रोग्राम लिखा है जो इस तंत्र का उपयोग करके खुद को डीबग करने का प्रबंधन करता है। पूरी तरह से बेकार, लेकिन शैक्षणिक।


डीबगर काम कैसे करता है इसका विवरण इस बात पर निर्भर करेगा कि आप क्या डिबगिंग कर रहे हैं, और ओएस क्या है। विंडोज़ पर देशी डिबगिंग के लिए आप एमएसडीएन पर कुछ विवरण पा सकते हैं: Win32 डीबगिंग एपीआई

उपयोगकर्ता डीबगर को बताता है जो या तो नाम या प्रक्रिया आईडी द्वारा संलग्न करने की प्रक्रिया करता है। यदि यह एक नाम है तो डीबगर प्रक्रिया आईडी को देखेगा, और सिस्टम कॉल के माध्यम से डीबग सत्र शुरू करेगा; विंडोज के तहत यह DebugActiveProcess होगा।

एक बार संलग्न होने पर, डीबगर किसी भी यूआई के लिए एक इवेंट लूप दर्ज करेगा, लेकिन विंडोिंग सिस्टम से आने वाली घटनाओं के बजाय, ओएस डीबग किए जाने की प्रक्रिया में क्या होता है, इस पर आधारित घटनाएं उत्पन्न करेगा - उदाहरण के लिए एक अपवाद होता है। WaitForDebugEvent देखें।

डीबगर लक्ष्य प्रक्रिया 'वर्चुअल मेमोरी को पढ़ने और लिखने में सक्षम है, और ओएस द्वारा प्रदान किए गए एपीआई के माध्यम से अपने रजिस्टर मानों को भी समायोजित करने में सक्षम है। विंडोज के लिए डिबगिंग कार्यों की सूची देखें।

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

यदि आप एक प्रबंधित वातावरण (.NET, Java, आदि) को डिबग कर रहे हैं, तो प्रक्रिया आम तौर पर समान दिखाई देगी, लेकिन विवरण अलग-अलग हैं, क्योंकि वर्चुअल मशीन वातावरण अंतर्निहित ओएस की बजाय डीबग API प्रदान करता है।


मेरी समझ यह है कि जब आप किसी एप्लिकेशन या डीएलएल फ़ाइल को संकलित करते हैं, तो जो कुछ भी संकलित करता है वह कार्यों और चर का प्रतिनिधित्व करने वाले प्रतीक होते हैं।

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


यदि आप विंडोज ओएस पर हैं, तो इसके लिए एक महान संसाधन जॉन रॉबिन्स द्वारा "माइक्रोसॉफ्ट .NET और माइक्रोसॉफ्ट विंडोज के लिए डिबगिंग अनुप्रयोग" होगा:

(या यहां तक ​​कि पुराना संस्करण: "अनुप्रयोगों को डीबग करना" )

इस पुस्तक में एक अध्याय है कि एक डीबगर कैसे काम करता है जिसमें कुछ सरल (लेकिन काम करने वाले) डिबगर्स के लिए कोड शामिल होता है।

चूंकि मैं यूनिक्स / लिनक्स डीबगिंग के विवरण से परिचित नहीं हूं, इसलिए यह सामान अन्य ओएस के लिए बिल्कुल लागू नहीं हो सकता है। लेकिन मुझे लगता है कि एक जटिल विषय के परिचय के रूप में अवधारणाओं - यदि विवरण और एपीआई नहीं हैं - तो किसी भी ओएस को 'पोर्ट' करना चाहिए।





internals