2010-05-24 10 views
7

तो मुझे क्या करना --strip-debug या --strip-unneeded, मैं .konm के साथ सभी फ़ंक्शन नाम को सूचीबद्ध करती है, अगर मैं मैं एक कर्नेल मॉड्यूल लोड करने के लिए मना कर दिया है बस strip foo.ko करते हैं।मैं स्थानीय प्रतीक को लिनक्स कर्नेल मॉड्यूल से तोड़ने के बिना कैसे छीन सकता हूं?

क्या किसी को त्वरित शॉर्टकट पता है कि मॉड्यूल लोडिंग के लिए आवश्यक सभी प्रतीकों को कैसे हटाया जाए ताकि लोग एपीआई को आसानी से इंजीनियर नहीं कर सकें?

पीएस: आप सभी के लिए खुला स्रोत bigots मिशनरी; यह ऐसा कुछ है जो सामान्य जनता किसी भी मामले में कभी भी उपयोग नहीं करेगा, इसलिए सवाल को जीपीएल लौ युद्ध में बदलने की जरूरत नहीं है।

+6

यदि आप वास्तव में लौ युद्ध से बचना चाहते हैं, तो मैं सुझाव देता हूं कि लोगों को बड़े पैमाने पर सामान्यीकृत न करें :) –

+0

अच्छा बिंदु, टिम :) अब बेहतर है? : डी – Kimvais

+2

यदि "सामान्य सार्वजनिक" आपका कोड कभी नहीं देखेगा तो आप रिवर्स इंजीनियरिंग के बारे में चिंतित क्यों हैं? –

उत्तर

7
मेरे पिछले सवाल कोई जवाब नहीं के साथ

, यहाँ कुछ अनुमान भी कुछ सुराग हो सकता है, और एक जवाब के लिए एक कदम हैं:

मैं क्या याद से, एक .ko कुछ नहीं बल्कि एक ओ फ़ाइल जिसके परिणामस्वरूप आपके स्रोत मॉड्यूल द्वारा उत्पन्न सभी .o फ़ाइलों के विलय से, और .modinfo अनुभाग के अतिरिक्त। किसी भी .ko बिल्डिंग मेकफ़ाइल के अंत में, एक एलडी कॉल है: जो मुझे याद है, एलडी को -r विकल्प के साथ बुलाया जाता है, और यही वह है जो .o फ़ाइल बनाता है जिसे मेकफ़ाइल कॉल करता है .ko। इस परिणामी फ़ाइल को किसी संग्रह या ऑब्जेक्ट लाइब्रेरी (.a फ़ाइल) के साथ भ्रमित नहीं किया जाना चाहिए, जो सिर्फ एक प्रारूप संग्रह/पैकेजिंग एकाधिक .o फाइलों के रूप में एक है: एक विलय ऑब्जेक्ट एक लिंक का परिणाम है जो अभी तक एक और उत्पन्न करता है .o मॉड्यूल: लेकिन परिणामी मॉड्यूल में, विलय किए जा सकने वाले सभी वर्ग रहे हैं, और सभी सार्वजनिक/बाहरी जोड़े जिन्हें हल किया जा सकता है उन वर्गों के अंदर हैं। तो मुझे लगता है कि आप अपने .ko अपने सभी "स्थानीय" extern परिभाषाएँ युक्त फ़ाइल के साथ अंत:

  • उन है कि निर्वासन हैं क्योंकि वे अपने .ko में मॉड्यूल ओ भर में कॉल करने के लिए उपयोग किया जाता है (लेकिन अब कोई आवश्यकता नहीं कर रहे हैं क्योंकि वे बाहर .ko से बुलाया जाना चाहिए नहीं कर रहे हैं), और

  • उन है कि .ko मॉड्यूल की जरूरत है ठीक से लोडर और कर्नेल के साथ संवाद।

पूर्व सबसे अधिक संभावना पहले से ही मर्ज के दौरान ld द्वारा हल किया गया है, लेकिन ld कोई रास्ता नहीं पता है कि आप उन्हें भी .ko बाहर से प्रतिदेय है करने का इरादा किया है।

तो आपके द्वारा देखे जाने वाले अपरिवर्तनीय प्रतीक वे हैं जो आपकी प्रत्येक .o फाइलों के लिए बाहरी हैं, लेकिन परिणामी .ko के लिए बाहरी के रूप में आवश्यक नहीं हैं। और जो आप खोज रहे हैं वह केवल उनको पट्टी करने का एक तरीका है।

क्या यह अंतिम अनुच्छेद उन प्रतीकों का सही वर्णन करता है जिन्हें आप छुटकारा पाने के लिए चाहते हैं?

+0

मुझे लगता है कि यह वही है जो हम यहां के बारे में बात कर रहे हैं। पहले अपडेट नहीं करने के लिए खेद है। किसी भी मामले में, जो आप यहां कहते हैं वह सही समझ में आता है और मुझे आगे की जांच करनी होगी। – Kimvais

3

मुझे यकीन है कि मैं समझता हूँ कि समस्या क्या वास्तव में है नहीं कर रहा हूँ: जब एक .ko विकास, अगर मैं स्पष्ट रूप से

ccflags-y += -ggdb -O0 -Wall 

की तरह कुछ न जोड़ें मेरी Makefile में, मैं किसी भी नहीं मिलता है प्रतीक लेकिन उन लोगों के लिए जो मैं प्रकाशित करता हूं या बाहरी खुद को रेफरी करता हूं। मुझे यकीन है कि मैं कई अच्छे कारणों के लिए किसी भी अन्य प्रतीक नहीं मिलता हूँ:

  • जिसके परिणामस्वरूप .ko फ़ाइल काफी छोटा होता है,
  • फ़ाइल डंपिंग और ईएलएफ का विश्लेषण करने से पता चलता टेबल वहाँ,
  • नहीं हैं
  • मैं kgdb में प्रतीकों को नहीं देख सकता और न ही देख सकता हूं।

तो मैं आपके प्रश्न पर थोड़ा उलझन में हूं, वास्तव में ... ... उन प्रतीकों को आप अपने .ko (और नहीं चाहते हैं) में क्या देख रहे हैं? वे आपकी स्रोत फ़ाइल में कैसे घोषित किए जाते हैं? ईएलएफ अनुभागों में वे किस प्रकार समाप्त होते हैं? और (क्षमा करें, बेवकूफ सवाल आगे): क्या आपने उन सभी चीजों को परिभाषित किया था जिन्हें अपने मॉड्यूल के बाहर देखने की आवश्यकता नहीं थी?

+0

नहीं, वे वहां 'ओएस' और ''g' -flags के साथ समाप्त होते हैं। – Kimvais

6

I think this is exactly what we are talking about here.

ठीक है, तो ऐसा लगता है कि एक समाधान "मैन्युअल रूप से" बाहरी प्रतीकों को हटाने के लिए है। "स्ट्रिप" उपयोगिता अलग-अलग प्रतीकों को अलग-अलग (या रखने) की अनुमति देती है, इसलिए आपको एक - स्ट्रिप-सभी और --keep-symbol = का एक छोटा गुच्छा उपयोग करना होगा। ध्यान दें कि - विल्डकार्ड थोड़ा सा भी मदद कर सकता है। आप सबसे सुविधाजनक क्या है, इसके आधार पर, आप बिल्कुल विपरीत और व्यक्तिगत रूप से पट्टी रख सकते हैं। बस init और बाहर निकलने की तरह स्पष्ट उपयोगी हैं, बातें छोड़ने -

एक अच्छी शुरुआत सभी प्रतीकों कि आप स्पष्ट रूप से पार मॉड्यूल जोड़ने के लिए अपने मॉड्यूल में परिभाषित और प्रकट करने के लिए नहीं करना चाहते हैं दूर करने के लिए हो सकता है। और उन लोगों को छूने के लिए जो कर्नेल देव सॉफ्टवेयर आधारभूत संरचना से उत्पन्न/संबंधित हैं। फिर परीक्षण और त्रुटि जब तक आप सही नुस्खा नहीं पाते ... असल में, मुझे लगता है कि आपके सभी प्रतीकों के बारे में उन लोगों के अलावा हटाया जा सकता है, जिन्हें आपने स्पष्ट रूप से EXPORT_SYMBOL (और निश्चित रूप से init/exit) के रूप में परिभाषित किया है।

शुभकामनाएं! :)

पुनश्च:

वास्तव में, ऐसा लगता है कि आवश्यक स्रोत की जानकारी .ko सभी परियोजनाओं में मौजूद करने के लिए आवश्यक स्वचालित रूप से अलग करना: जब तक मैं कुछ याद कर रहा हूँ, ऐसा लगता है कि कुछ भी है कि EXPORT_SYMBOL नहीं कर रहा है या बिल्ड सॉफ़्टवेयर द्वारा स्पष्ट रूप से डाला गया सैद्धांतिक रूप से "ld -r" समय के अंत में डिफ़ॉल्ट रूप से अलग हो सकता है जो एक .ko बिल्ड समाप्त होता है। यह सिर्फ इतना नहीं है कि मुझे नहीं लगता कि टूलचेन (कंपाइलर/लिंकर) में स्थानापन्न लिंक/मर्ज के लिए अलग-अलग "पट्टी या रखरखाव" सिम्स को नामित करने के लिए प्रावधान/निर्देश/विकल्प हैं। अन्यथा, EXPORT_SYMBOL मैक्रो और कुछ अन्य स्थानों में कुछ संशोधन संभवतः आपके द्वारा प्राप्त किए गए परिणाम को प्राप्त कर सकते हैं, और किसी भी लिनक्स सिस्टम में अधिकांश .ko फ़ाइलों से कुछ बाइट शेव कर सकते हैं।

+0

ठीक है, इस प्रकार का प्रश्न इस प्रकार बदलता है - '* _init()', '* _exit()' और 'जिन्हें मैं स्पष्ट रूप से' EXPORT_SYMBOL() 'से अधिक की आवश्यकता है? - या यह वास्तव में सब है? – Kimvais

+0

यही कारण है कि मैंने बताया कि यह परीक्षण और त्रुटि होगी: मुझे पूरा यकीन नहीं है, मुझे पहले कभी भी उस खेल को खेलना नहीं था। मैं किसी भी प्रतीक में अकेले छोड़कर शुरू करूंगा, मैंने खुद को नहीं रखा है, और कुछ भी हटा रहा है जो मेरे अपने स्रोत मॉड्यूल में कॉल कर रहा है और संभवतः .ko ld द्वारा हल किया गया है। यदि यह काम करता है, तो मैं इस से शुरू करूंगा और कुछ और सफाई, टुकड़े टुकड़े, परीक्षण, और इस तरह पुनरावृत्ति करने की कोशिश करता हूं। बहुत अनुभवजन्य, लेकिन बिल्ली ... अगर यह आपकी समस्या हल करता है, तो यह काफी अच्छा हो सकता है। – filofel

1

filofel पद के अलावा:

कारण यूज़रस्पेस साझा पुस्तकालयों अलग करना उन्हें कार्य कर रहा है, क्योंकि उनके निर्यात प्रतीकों .dynsym अनुभाग जो छीन लिया कभी नहीं किया गया है में हैं रहता है। .ko फ़ाइलें हालांकि dynsym का उपयोग नहीं करते हैं।

1

लोग मैं सिर्फ कर्नेल config साकार डिबग प्रतीकों सक्षम था के बिना एक कर्नेल बनाया

strip --strip-unneeded 
+0

यह वास्तव में इस ध्वज के साथ क्या पट्टी करता है? – aisbaa

5

के साथ सफलता की सूचना दी है, तो जिसके परिणामस्वरूप मॉड्यूल का आकार काफी बड़े थे। यह मेरे लिए काम किया:

# du -sh /lib/modules/3.1.0/ 
1.9G /lib/modules/3.1.0/ 
# find /lib/modules/3.1.0/ -iname "*.ko" -exec strip --strip-debug {} \; 
# du -sh /lib/modules/3.1.0/ 
134M /lib/modules/3.1.0/ 

/lib/modules/3.1.0*.ko नामित में सभी फाइलों का पता लगाएं और इनमें से प्रत्येक पर strip --strip-debug निष्पादित।

0

strip -g XXX.

क्या आप हुआ Linux Kernel 3.0.8 साथ एम्बेडेड उपकरण में इस आदेश से sloved है की तरह अपने पिछले समस्या।

+0

मैंने कुछ परीक्षण और त्रुटि के माध्यम से सीखा है कि कर्नेल मॉड्यूल पर 'strip -g' का उपयोग करके सामान्य रूप से उत्पादित' * .ko' को परिवर्तित नहीं किया जाता है। हालांकि, एक सहयोगी के साथ सहयोग के माध्यम से, ऐसा लगता है कि जीसीसी विकल्प '-g0' * का उपयोग * डीबगिंग प्रतीकों को प्रभावित करता है। मुझे संदेह है क्योंकि यह कर्नेल मॉड्यूल अन्य मॉड्यूल की तुलना में थोड़ा अलग है: [इस जवाब को देखें] (https://stackoverflow.com/a/4238266/988207) इस धागे के भीतर। –

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