2009-08-14 14 views
10

यदि एक ही कोड विभिन्न समय w/gcc पर बनाया गया है, परिणामी बाइनरी में अलग-अलग सामग्री होगी। ठीक है, मैं इसके बारे में जंगली नहीं हूं, लेकिन यही वह है।जीसीसी संकलित बाइनरी w/विभिन्न आकार?

हालांकि, मैंने हाल ही में ऐसी स्थिति में भाग लिया है जहां जीसीसी के समान संस्करण के साथ बनाया गया एक ही कोड, पूर्व निर्माण (लगभग 1 9 00 बाइट्स) से अलग आकार के साथ बाइनरी उत्पन्न कर रहा है।

क्या किसी को भी कोई विचार है कि इन स्थितियों में से कोई भी क्या हो सकता है? क्या यह किसी प्रकार का ईएलएफ मुद्दा है? क्या वहां कोई उपकरण है (एलडीडी के अलावा) जिसका उपयोग बाइनरी की सामग्री को डंप करने के लिए किया जा सकता है ताकि यह देखने के लिए कि वास्तव में क्या अलग है?

अग्रिम धन्यवाद।

उत्तर

3

एक अनुकरणीय उदाहरण में मदद मिलेगी:

  • आप अन्य बाहरी पुस्तकालयों का उपयोग करें?
  • क्या आप स्थिर या गतिशील रूप से लिंक करते हैं?
  • क्या आपने -O या -s जैसे ध्वज बदल दिए थे?
+1

कंपाइलर झंडे पहली बात है जो मेरे दिमाग में भी आई है। खासकर कुछ जैसे- ओ। –

1

इस तरह की asked before किया गया गया है, और जवाब यह है कि संकलक की आंतरिक स्थिति अच्छी तरह से अलग संकलक रन है, जो विभिन्न कोड में परिणाम कर सकते उत्सर्जित कर दिया गया पर अलग अलग है और इस तरह अलग अलग आकार आ रही है।

+0

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

+0

... कहा जा रहा है कि आपके द्वारा दिए गए उत्तर वास्तव में यहां एक अच्छा है। –

+0

खैर, प्लेटफॉर्म समान होना चाहिए। (सबकुछ समर्पित बिल्ड सर्वर से बनाया गया है)। तो, हम जो पता लगाने की कोशिश कर रहे हैं वह यह है कि यह गलत हो गया है। – BillTorpey

8

objdump शायद वह कार्यक्रम है जिसे आप बाइनरी की सामग्री को डंप करने के लिए देख रहे हैं।

objdump -h आपको अनुभाग और उनके आकार दिखाएगा, इसलिए आपको यह देखने में सक्षम होना चाहिए कि आकार परिवर्तन कहां हो रहा है और फिर आगे देखने के लिए आगे बढ़ें।

1

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

मुझे याद है कि उस समय कुछ लोग इस बात से चिंतित थे। यह विशेष रूप से उन लोगों के लिए मामला था जो परिणामस्वरूप द्विआधारी में भिन्नता से स्रोत परिवर्तनों की जांच करना पसंद करते थे। तब मेरी सलाह है कि अब इसे खत्म करना है। स्रोत आप "diff" कर सकते हैं। द्विआधारी के लिए केवल गारंटी यह है कि एक ही स्रोत फाइलों से संकलित दोनों निष्पादन योग्य वही करेंगे जो आपने उन्हें करने के लिए कहा था।

+0

मुझे लगता है कि यह बहुत महत्वपूर्ण है कि जब आप कंपाइलर को एक ही स्रोत कोड और समान बिल्ड सेटिंग्स देते हैं, तो यह हमेशा सटीक उसी निष्पादन योग्य, बाइट-फॉर-बाइट आउटपुट करता है। अन्यथा, अगर ऑप्टिमाइज़र में कोई बग है, तो आप निष्पादन योग्य बनने के समय स्वतंत्र रूप से होने वाली रैम की मात्रा पर आधारित "काम करने" और कुछ "नहीं" के साथ समाप्त हो सकते हैं। .. वास्तव में डीबग करने के लिए एक दुःस्वप्न! यहां तक ​​कि यदि संकलक बग फ्री था, तो भी आपके कुछ बिल्ड सभी मामलों की तुलना में तेजी से चलेंगे, हालांकि सभी मामलों में स्रोत कोड समान है। –

+0

आपको यह चाहिए, लेकिन जैसा कि टेड और मैंने इंगित किया है, आप इसे प्राप्त नहीं कर सकते हैं। –

+0

एक संदर्भ प्रदान करने के लिए देखभाल जो दिखाती है कि जीसीसी के पास यह टूटा व्यवहार है, क्योंकि ओपी का सवाल यही है? – caf

0

कंपाइलर के अतिरिक्त आपको उन मानक पुस्तकालयों की जांच करने की आवश्यकता है जिन्हें आप लिंक करते हैं। उनके संस्करण की जांच करें और सत्यापित करें कि वे नहीं बदला है।

0

अन्यथा समान निर्माण के बीच आकार में अंतर के लिए एक संभावित कारण यह है कि बाइनरी में संग्रहीत चर-आकार की जानकारी हो सकती है। कुछ उदाहरण:

  • संकलक संकलन में invoved फ़ाइलों के बारे में डाल जा सकता पथ/नाम की जानकारी, या तो जानकारी डीबगिंग के लिए या __FILE__ मैक्रो के उपयोग के कारण। यह संभव है कि यह अपने स्वयं के उद्देश्यों के लिए ऐसा कर सके जिनके पास इनमें से किसी भी चीज़ से कोई लेना देना नहीं है। यदि निर्माण अलग-अलग मशीनों पर भी थोड़ा अलग निर्देशिका संरचना के साथ होता है, तो यह बाइनरी में अंतर के लिए जिम्मेदार हो सकता है।
  • इसी तरह निर्माण के दिनांक/समय के लिए, हालांकि मुझे उम्मीद है कि इन्हें बाइनरी में बहुत कम बार मिल जाएगा (लेकिन मुझे क्या पता है?)।यदि यह एक योगदान कारक था, तो आप एक ही मशीन पर समान निर्माण से अलग-अलग आकारों को देख सकते थे, बस अलग-अलग enuogh समय पर।

ये चीजें बिल्ड मशीन, as Neil Butterworth pointed out की स्थिति में भिन्नता के लिए उबालती हैं।

8

मैंने कम से कम मेरी संतुष्टि के लिए चीजों को हल करने में कामयाब रहा है, और जो कुछ मैंने पाया है उसे पारित करना चाहता था।

रीडेल का उपयोग करके, (readelf -a -W) मैंने दोनों बिल्डों की सामग्री सूचीबद्ध करने की एक रिपोर्ट बनाई और तुलना की तुलना में (तुलना से परे)। इससे पता चला कि बूस्ट libs से कुछ अतिरिक्त प्रतीकों को खींच लिया जा रहा था।

लो और देखें, हम वास्तव में एक निर्भर पुस्तकालय के एक अलग संस्करण के खिलाफ निर्माण कर रहे थे और इसे महसूस नहीं किया। इस मामले में कोई नुकसान नहीं हुआ, लेकिन यह जानना अच्छा है कि आपके निष्पादन योग्य में क्या हो रहा है।

विचारशील उत्तरों के लिए सभी को धन्यवाद।

संबंधित मुद्दे