2012-10-09 23 views
9

मैं लिनक्स प्लेटफ़ॉर्म पर 64-बिट पर एप्लिकेशन को पोर्ट करने पर काम कर रहा हूं। एप्लिकेशन वर्तमान में लिनक्स, विंडोज, मैक 32-बिट और विंडोज 64-बिट पर समर्थित है। जिन मुद्दों का हम अक्सर सामना कर रहे हैं उनमें से एक int और इसके विपरीत के लिए लंबे समय तक उपयोग है। अब तक यह कोई समस्या नहीं थी क्योंकि लंबे समय से और int प्लेटफॉर्म में इंटरचेंज करने योग्य (दोनों 4 बाइट्स) हैं, एप्लिकेशन वर्तमान में समर्थित है। कोडबेस एक विशाल व्यक्ति है, जिसमें कई डेटा प्रकारों के लिए #defines के साथ विरासत कोड बहुत सारे हैं, यह लंबे समय तक सभी उपयोगों को खोजने और int के साथ उचित रूप से प्रतिस्थापित करने के लिए बोझिल बनाता है।64-बिट लिनक्स मशीन पर जीसीसी में 'लंबे' 4 बाइट बनाना

  1. एक अल्पकालिक समाधान के रूप में, क्या जीसीसी को 'लंबे' के लिए 8 के बजाय 4 बाइट्स बनाने का कोई तरीका है?
  2. यदि यह है, तो हमें क्या समस्याएं आ सकती हैं? यदि नहीं, तो लंबी और int समस्या को ठीक करने का कोई आसान तरीका है?
+5

यह आपकी तत्काल समस्या (इसलिए टिप्पणी) का समाधान नहीं है, लेकिन भविष्य के कोड के लिए मैं इसके बजाय सटीक चौड़ाई प्रकार का उपयोग करूंगा (उदा।, 'Uint32_t')। –

उत्तर

6
  1. सं लिनक्स पर x86_64 ABI निर्दिष्ट करता है कि लंबे समय से एक 8 बाइट प्रकार (LP64) है। असल में, यदि सभी 64-बिट यूनिक्स सिस्टम (64-बिट ओएस एक्स, AFAIK समेत) एलपी 64 नहीं हैं तो यह लिनक्स के लिए विशिष्ट नहीं है।

  2. अपने कोड को ठीक करने के अलावा, नहीं। इसलिए

आप एक पोर्टेबल पूर्णांक प्रकार जो इतना बड़ा, एक सूचक मान संग्रहीत intptr_t या uintptr_t का उपयोग करें (लेकिन आम तौर पर में एक पूर्णांक मतलब है कि आप कुछ गलत कर रहे हैं एक सूचक मान संग्रहीत के लिए इच्छुक है की जरूरत है, दो बार सोचो!)। एक पूर्णांक प्रकार के लिए जो दो पॉइंटर्स के बीच अंतर का प्रतिनिधित्व करने में सक्षम है, ptrdiff_t का उपयोग करें। वस्तुओं के आकार के लिए, size_t का उपयोग करें।

+0

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

5

-m32 32-बिट कोड उत्पन्न करता है।

-mx32 64-बिट कोड उत्पन्न करता है लेकिन 32-बिट लंबे और पॉइंटर्स का उपयोग करता है।

Intel 386 and AMD x86-64 Options

+0

लेकिन यह 64 बिट लंबे समय तक सिस्टम पुस्तकालयों के साथ कैसे बातचीत करेगा? – johv

+0

मूल पोस्टर को 32 बिट्स होने की आवश्यकता होती है, इसलिए उन्हें 32 बिट डेटा के साथ काम करने वाले पुस्तकालयों से लिंक करने की आवश्यकता होती है। मुझे लगता है कि जब एक समारोह को कॉल किया जाता है, जब इसे 32 बिट पैरामीटर की आवश्यकता होती है, तो यह परवाह नहीं करता कि कॉलर के डेटाटाइप क्या है, और यह परवाह नहीं है कि कॉलर सी फ़ंक्शन था या नहीं। लेकिन हां, कॉलर को यह सुनिश्चित करना होगा कि 64 बिट मानों की अपेक्षा रखने वाली लाइब्रेरी को कॉल न करें। –

+2

@johv: यह नहीं होगा। -32 के साथ आपको "सामान्य" 32-बिट x86 एबीआई के साथ पुस्तकालयों का उपयोग करने की आवश्यकता है, -xx32 के साथ आपको X32 पुस्तकालयों की आवश्यकता है। – janneb