Jmp_buf संरचना में प्रत्येक प्रविष्टि क्या रखती है?

Question

मैं उबंटू 9 .10 (कर्मिक कोआला) चला रहा हूं, और मैंने jmp_buf संरचना पर एक नज़र डाली जो कि केवल 12 इंच की एक सरणी है। जब मैं setjmp का उपयोग करता हूं, और jmp_buf संरचना — में से 12 प्रविष्टियों को सहेजा जाता है। ये 4 प्रविष्टियां स्टैक पॉइंटर, फ्रेम पॉइंटर, प्रोग्राम काउंटर और रिटर्न पता हैं। के लिए अन्य 8 प्रविष्टियां क्या हैं? क्या वे मशीन-निर्भर हैं? सेगमेंट टेबल बेस रजिस्टर में एक और प्रविष्टि है? धागे/प्रक्रिया के पर्यावरण को सही तरीके से बहाल करने के लिए और क्या चाहिए? मैंने मैन पेज, अन्य स्रोतों को देखा, लेकिन मुझे setjmp के लिए असेंबली कोड नहीं मिला।

Answer 1

MacOS एक्स 10.6.2 पर, शीर्ष लेख <setjmp.h><i386/setjmp.h> का उपयोग कर समाप्त होता है, और वहाँ में यह कहते हैं:

#if defined(__x86_64__) 
/* 
* _JBLEN is number of ints required to save the following: 
* rflags, rip, rbp, rsp, rbx, r12, r13, r14, r15... these are 8 bytes each 
* mxcsr, fp control word, sigmask... these are 4 bytes each 
* add 16 ints for future expansion needs... 
*/ 
#define _JBLEN ((9 * 2) + 3 + 16) 
typedef int jmp_buf[_JBLEN]; 
typedef int sigjmp_buf[_JBLEN + 1]; 

#else 

/* 
* _JBLEN is number of ints required to save the following: 
* eax, ebx, ecx, edx, edi, esi, ebp, esp, ss, eflags, eip, 
* cs, de, es, fs, gs == 16 ints 
* onstack, mask = 2 ints 
*/ 

#define _JBLEN (18) 
typedef int jmp_buf[_JBLEN]; 
typedef int sigjmp_buf[_JBLEN + 1]; 

#endif 

आप शायद लिनक्स पर समान आवश्यकताओं मिलेगा - jmp_buf आवश्यक स्टोर करने के लिए पर्याप्त जानकारी शामिल है राज्य। और, इसका उपयोग करने के लिए, आपको वास्तव में यह जानने की आवश्यकता नहीं है कि इसमें क्या शामिल है; आपको बस इतना करना है कि कार्यान्वयन करने वालों को यह सही हो गया। यदि आप कार्यान्वयन को बदलना चाहते हैं, तो आपको निश्चित रूप से इसे समझने की आवश्यकता है।

ध्यान दें कि setjmp और longjmp बहुत मशीन विशिष्ट हैं। उन्हें लागू करने में शामिल कुछ मुद्दों की चर्चा के लिए प्लोगर का "The Standard C Library" पढ़ें। अधिक आधुनिक चिप्स वास्तव में अच्छी तरह से लागू करने के लिए कठिन बनाते हैं।

Answer 2

setjmp/longjmp/sigsetjmp CPU वास्तुकला, ऑपरेटिंग सिस्टम, और सूत्रण मॉडल पर निर्भर कर रहे हैं। पहले दो फ़ंक्शंस (या कुख्यात रूप से-आपके पीओवी के आधार पर) मूल यूनिक्स कर्नेल में एक असफल सिस्टम कॉल से बाहर निकलने के लिए "संरचित" तरीके के रूप में दिखाई दिए, जैसे कि I/o त्रुटि या अन्य ग़लत स्थितियों से।

/usr/include/setjmp.h में संरचना की टिप्पणी (लिनक्स फेडोरा) का कहना है कि कॉलिंग पर्यावरण, प्लस संभवतः एक बचाया संकेत मुखौटा। इसमें jmp_buf को छह 32-बिट इन्ट्स की सरणी रखने के लिए /usr/include/bits/setjmp.h शामिल है, जो कि स्पष्ट रूप से x86 परिवार के लिए विशिष्ट है।

जबकि मुझे PPC implementation के अलावा अन्य स्रोत नहीं मिला, तो टिप्पणियों ने संकेत दिया कि एफपीयू सेटिंग्स को सहेजा जाना चाहिए। राउंडिंग मोड को पुनर्स्थापित करने में विफल होने के बाद से यह समझ में आता है, डिफ़ॉल्ट ऑपरेंड आकार, अपवाद हैंडलिंग इत्यादि आश्चर्यजनक होगा।

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