gdb एएलएफ कोर फ़ाइल प्रारूप




core elf (4)

जीडीबी स्रोत के माध्यम से खुदाई की कमी, कोर फाईल्स बनाने के लिए प्रयुक्त प्रारूप के बारे में मैं दस्तावेज़ कहां मिल सकता हूं?

एएलएफ विनिर्देशन कोर फाइल स्वरूप को खुले छोड़ देता है, इसलिए मुझे लगता है कि यह GDB विनिर्देशों का हिस्सा होना चाहिए! दुर्भाग्य से, मुझे इस संबंध में जीएनयू के जीडीबी प्रलेखन से कोई मदद नहीं मिली।

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

अब 'रीडेल-ए कोर' कहता है कि कोर फाइल में लगभग सभी खंड प्रकार 'लोड' होते हैं - मुझे लगता था कि ये सभी भाग लेने वाली फाइलों के .text और .bss / .data सेगमेंट हैं प्लस एक स्टैक सेगमेंट इन लोड सेगमेंट को छोड़कर, एक नोट सेगमेंट है, लेकिन इसमें मानचित्र शामिल नहीं है तो कैसे एक फाइल के बारे में जानकारी से मेल खाती है, कोर फ़ाइल में संग्रहीत है? क्या उन 'भार' खंडों को फाइल की जानकारी शामिल करने के लिए विशेष रूप से प्रारूपित किया जाता है?


मुख्य डंप फ़ाइल स्वरूप ELF प्रारूप का उपयोग कर रहा है लेकिन इसका वर्णन ELF मानक में नहीं है। AFAIK, इस पर कोई आधिकारिक संदर्भ नहीं है।

तो एक फाइल किस सेगमेंट से संबंधित है, कोर फ़ाइल में संग्रहीत जानकारी किस प्रकार है?

ELF नोट्स के भीतर बहुत अधिक अतिरिक्त जानकारी शामिल है आप उन्हें देखने के लिए readelf -n का उपयोग कर सकते हैं।

कोर / एनटीआईईईएल नोट मेमोरी एड्रेस रेंज और फाइल (+ ऑफसेट) के बीच के संबंध को परिभाषित करता है:

Page size: 1
             Start                 End         Page Offset
0x0000000000400000  0x000000000049d000  0x0000000000000000
    /usr/bin/xchat
0x000000000069c000  0x00000000006a0000  0x000000000009c000
    /usr/bin/xchat
0x00007f2490885000  0x00007f24908a1000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908a1000  0x00007f24908bd000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908bd000  0x00007f2490eb0000  0x0000000000000000
    /usr/share/fonts/opentype/ipafont-gothic/ipag.ttf
[...]

प्रत्येक थ्रेड के लिए, आपके पास एक CORE/NT_PRSTATUS नोट होना चाहिए जो आपको थ्रेड के रजिस्टरों (स्टैक पॉइंटर सहित) देता है। आप इस से ढेर की स्थिति का आकलन करने में सक्षम हो सकते हैं

एएलएफ कोर फाइलों के स्वरूप के बारे में अधिक जानकारी:


bfd , binutils , आदि द्वारा उपयोग किए गए bfd लाइब्रेरी के रूप में बहुत ज्यादा gdb नहीं।


एक मुख्य डंप प्रक्रिया के इन-मेमोरी छवि होती है जब यह क्रैश हो जाता है। इसमें प्रोग्राम खंड, स्टैक, ढेर और अन्य डेटा शामिल हैं। सामग्रियों को समझने के लिए आपको अभी भी मूल कार्यक्रम की आवश्यकता होगी: प्रतीक तालिकाओं और अन्य डेटा को सार्थक छवियों में स्मृति के रूप में कच्चे पते और संरचनाएं बनाते हैं।


आपकी समस्या का एक आसान समाधान / proc / $ pid / maps से पाठ को पार्स करने के लिए हो सकता है कि यह निर्धारित करने के लिए कि कोई दिए गए वर्चुअल पता नक्शे को किस फाइल में भेज दिया जाए। तब आप इसी फ़ाइल को पार्स कर सकते हैं

केन्शोटो के ओपन सोर्स वीडीबी (डीबगर) इस दृष्टिकोण का उपयोग करता है, अगर आप अजगर पढ़ सकते हैं तो यह एक अच्छा उदाहरण है।