सभी कोड संकलित स्थिति स्वतंत्र क्यों नहीं है?

Question 1

जब gcc -fPIC विकल्प में साझा पुस्तकालयों का संकलन कोड को स्वतंत्र स्थिति के रूप में संकलित करता है। क्या कोई कारण है (प्रदर्शन या अन्यथा) आप सभी कोड स्थिति को स्वतंत्र क्यों नहीं संकलित करेंगे?

Question 2

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

Question 3

यह आलेख बताता है कि PIC कैसे काम करता है और इसकी तुलना वैकल्पिक लोड लोड स्थानांतरण से करता है । मुझे लगता है कि यह आपके प्रश्न के लिए प्रासंगिक है।

Question 4

हां प्रदर्शन के कारण हैं। कुछ अभिगमन स्मृति में पूर्ण स्थिति प्राप्त करने के लिए अप्रत्यक्ष की एक और परत के तहत प्रभावी रूप से होते हैं।

इसमें GOT (ग्लोबल ऑफ़सेट टेबल) भी है जो ग्लोबल वैरिएबल्स के ऑफ़सेट्स को स्टोर करता है। मेरे लिए, यह सिर्फ एक IAT फ़िक्सअप तालिका की तरह दिखता है, जिसे विकिपीडिया और कुछ अन्य स्रोतों द्वारा निर्भर स्थिति के रूप में वर्गीकृत किया गया है।

http://en.wikipedia.org/wiki/Position_independent_code

Question 5

स्वीकृत उत्तर के अतिरिक्त। एक चीज जो PIC कोड के प्रदर्शन को बहुत नुकसान पहुंचाती है वह है x86 पर "आईपी रिलेटिव एड्रेसिंग" की कमी। "आईपी रिलेटिव एड्रेसिंग" से आप उन डेटा की मांग कर सकते हैं जो वर्तमान निर्देश सूचक से एक्स बाइट्स हैं। इससे PIC कोड बहुत सरल हो जाएगा।

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

call label_1
.dd 0xdeadbeef
.dd 0xfeedf00d
.dd 0x11223344
label_1:
pop ebp            ; now ebp holds the address of the first dataword
                   ; this works because the call pushes the **next**
                   ; instructions address
                   ; real code follows
mov eax, [ebp + 4] ; for example i'm accessing the '0xfeedf00d' in a PIC way

यह और अन्य तकनीक डेटा एक्सेस तक अप्रत्यक्ष की एक परत जोड़ते हैं। उदाहरण के लिए, जीओटी (ग्लोबल ऑफ़सेट टेबल) जीसीसी संकलक द्वारा उपयोग किया जाता है।

x86-64 ने "RIP रिलेटिव" मोड जोड़ा, जो चीजों को बहुत सरल बनाता है।

Question 6

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

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

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

Question 7

इसके अलावा, अधिकांश आधुनिक प्रोसेसर (अधिकांश आधुनिक ओएस द्वारा उपयोग किए जाने वाले) में मेमोरी मेमोरी हार्डवेयर का मतलब है कि बहुत सारे कोड (सभी उपयोगकर्ता अंतरिक्ष ऐप, एमएमएपी या इसी तरह के क्वर्की उपयोग को छोड़कर) को स्वतंत्र होने की आवश्यकता नहीं है। प्रत्येक कार्यक्रम को अपना पता स्थान मिलता है जो यह सोचता है कि यह शून्य पर शुरू होता है।

Question 8

position-independent code अधिकांश आर्किटेक्चर पर एक प्रदर्शन ओवरहेड है, क्योंकि इसके लिए एक अतिरिक्त रजिस्टर की आवश्यकता होती है।

तो, यह प्रदर्शन उद्देश्य के लिए है।

Question 9

आजकल ऑपरेटिंग सिस्टम और संकलक डिफ़ॉल्ट रूप से सभी कोड को स्थिति स्वतंत्र कोड बनाते हैं। -FPIC ध्वज के बिना संकलन का प्रयास करें, कोड ठीक संकलित करेगा लेकिन आपको बस एक चेतावनी मिलेगी। इस तरह की खिड़कियां इसे प्राप्त करने के लिए मेमोरी मैपिंग नामक तकनीक का उपयोग करती हैं।

Question 10

2009 के लिए प्रश्न दिनांक। दस साल बीत चुके हैं, और अब सभी कोड वास्तव में स्वतंत्र स्थिति है। यह अब ऑपरेटिंग सिस्टम और कंपाइलर द्वारा लागू किया गया है। ऑप्ट-आउट करने का कोई तरीका नहीं है। सभी कोड को PIE के साथ बल-संकलित किया गया है, और-AS-R बहाने के हिस्से के रूप में -no-pic / -no-ध्वज ध्वज को अनदेखा किया जा रहा है। इसका कारण बढ़ी सुरक्षा की आड़ में पूर्व के तेज़ ऐप को धीमा करना और नए हार्डवेयर को बेचना है। यह पूरी तरह से तर्कहीन है, क्योंकि अब बड़े मेमोरी साइज हमें सभी ऐप्स को स्टेटिक रूप से कंपेयर करते हुए डायनेमिक लिंकिंग के नर्क से छुटकारा दिलाते हैं।

इससे पहले भी ऐसा ही हुआ था, जब लोगों ने चुपचाप असली मोड और अन्य स्वतंत्रता को स्वीकार किया था। संदर्भ स्विच और पता अनुवाद विलंबता के कारण, एमएमयू आपको भारी मंदी का सामना करना पड़ता है। आपको प्रदर्शन महत्वपूर्ण प्रणालियों में MMU नहीं मिलेगा, जैसे कि वैज्ञानिकों द्वारा भौतिकी प्रयोगों का नमूना लेने के लिए उपयोग किया जाता है।

आप शिकायत नहीं करते हैं, क्योंकि आप यह भी नहीं जानते हैं कि आपके कोड को इन सभी प्रशिक्षण पहियों द्वारा विकलांग किया जा रहा है। मैं क्या कह सकता हूँ? अब उनके PIC के साथ 2 बार धीमी गति से सॉफ्टवेयर का आनंद लें! इससे भी अधिक, LLVM के आगमन के साथ, जल्द ही वहाँ JIT (प्रबंधित कोड) लागू किया जाएगा, जिसमें x86 इनलाइन असेंबली का उपयोग नहीं होगा, जो किसी भी C / C ++ कोड को और धीमा कर देगा। "जो लोग सुरक्षा के लिए स्वतंत्रता का त्याग करते हैं वे न तो योग्य हैं।"