2012-11-02 24 views
5

के गलत संस्करण के लिए लिंक लिंक मैं एक ऐसी समस्या को डीबग करने का प्रयास कर रहा हूं जहां फ़ंक्शन के गलत संस्करण को सेगफॉल्ट के कारण बुलाया जाता है। कोड जिसे मैं संकलित कर रहा हूं वह मशीन जेनरेट की गई है और इसमें 'टाइम्स' नामक एक फ़ंक्शन शामिल है जो इसके दो तर्कों के जटिल गुणा करता है। उच्च कोड ऑब्जेक्ट फ़ाइल में लिंक होने से पहले यह कोड एक .o को संकलित किया गया है।सी प्रोग्राम फ़ंक्शन

इस कोड को चलाने के दौरान segfaults और gdb इंगित करता है कि यह 'times' के glibc के संस्करण में है जो तर्कों की संख्या को भी नहीं लेता है। इस कोड में कहीं भी शामिल # # शामिल नहीं हैं।

समय-समय पर नाम बदलने से समस्या हल हो जाती है। यह एक दीर्घकालिक समाधान नहीं है हालांकि कोड की मशीन उत्पन्न प्रकृति और मैन्युअल रूप से इस फ़ंक्शन के नाम को संपादित करने के कारण हर समय अपरिहार्य है।

पूरी गड़बड़ी के साथ सफाई संकलित करता है -वैसे तो मुझे यकीन नहीं है कि कहां देखना है। इसे हल करने के तरीके पर कोई विचार?

Compile chain: 
    gcc -Wall -I. -g --shared -o dpd.o -fPIC *.c (mahine generated code here) 
    gcc -g --std=c99 -c -fpic getData.c -I/usr/local/include -L/usr/local/lib -lmatio -I/usr/local/include/iverilog -I$(MATLAB) 
    gcc -g -shared -o getData.vpi getData.o $(MATLAB)/dpd.o -lvpi -lmatio -L/usr/local/lib 
+3

एकाधिक सी फाइलों को एक '.o' में संकलित करना पारंपरिक नहीं है। यदि इस समूह में संकलित कई सी फाइलों में से एक है 'times.c', यह समस्या की व्याख्या कर सकता है। – Gene

+1

एक '# शामिल' केवल घोषणाओं में लाता है; इसका लिंकिंग पर कोई नियंत्रण नहीं है। यदि आप 'टाइम्स' नामक फ़ंक्शन घोषित करते हैं और फिर इसे कॉल करते हैं, तो कंपाइलर एक ऑब्जेक्ट फ़ाइल उत्पन्न करेगा जिसमें उस नाम का संदर्भ उसके प्रतीक तालिका में होगा, और फिर अंतिम निष्पादन योग्य उत्पादन करते समय लिंकर उस नाम की परिभाषा की खोज करेगा । Libc में एक 'times' फ़ंक्शन है, और यही लिंकर मिला है। – Wyzard

+0

जीन - क्या आप अपनी टिप्पणी पर विस्तार कर सकते हैं? times.c वास्तव में एक अलग सी फ़ाइल है जो उस एकल वस्तु में संकलित है। आप इस समस्या का कारण बनने की उम्मीद क्यों करेंगे? वास्तव में केवल एक प्रविष्टि बिंदु है जिसके लिए मुझे रूचि है। और 'समय' उनमें से एक नहीं है। यानी यह पूरी तरह से आंतरिक होना चाहिए और उच्च परतों के लिए गतिशील प्रतीक के रूप में नहीं देखा जाना चाहिए। क्या इस बारे में जीसीसी बताने का कोई तरीका है? –

उत्तर

0

तो इसका वास्तविक जवाब -fno-builtin-times को जीसीसी में फेंकना है। यह किसी भी झगड़े के साथ अच्छी तरह से समस्या से परहेज करता है।

यह निश्चित रूप से मानता है कि आप times के नाम को किसी ग्लिबैक प्रदान किए गए फ़ंक्शन से टकराव नहीं कर सकते हैं।

3

सी केवल एक पहचानकर्ता के रूप में फ़ंक्शन का नाम उपयोग करता है, इसलिए एक ही नाम वाले किसी भी दो (निर्यात किए गए) फ़ंक्शन संघर्ष करेंगे। सामान्य दृष्टिकोण एक विशिष्ट उपसर्ग के साथ लाइब्रेरी में सभी निर्यात किए गए नामों को उपसर्ग करना है। दूसरा विकल्प सी ++ को "बेहतर सी" के रूप में उपयोग करना है और सी ++ कंपाइलर का उपयोग करके अपने सी कोड का निर्माण करना है, सी ++ नाम मैंगलिंग का उपयोग करना।

+0

इस मामले में लिंकर "डुप्लिकेट प्रतीक" के साथ चकित नहीं होना चाहिए? –

+0

जब तक कि आप इसे दो अलग-अलग फ़ाइलों में खींचने के लिए मजबूर नहीं करते हैं। – bmargulies

+0

@ एच 2CO3 यूनिक्स लिंकर्स * कभी भी शिकायत नहीं करते हैं जब एक ही प्रतीक मुख्य निष्पादन योग्य और साझा लाइब्रेरी ('libc.so.6') में परिभाषित किया जाता है - इस तरह का प्रतीक इंटरपोजिशनिंग काफी आम है और अक्सर बहुत उपयोगी होता है। –