पीवीएस-स्टूडियो में जीएनयू आर्म एंबेडेड टूलचिन के लिए समर्थन शामिल है

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

परिचय

PVS-Studio विश्लेषक पहले से ही एम्बेडेड सिस्टम के लिए कई वाणिज्यिक संकलकों का समर्थन करता है, उदाहरण के लिए:

• IAR एंबेडेड वर्कबेंच
• आर्म के लिए केइल एंबेडेड डेवलपमेंट टूल
• TI एआरएम कोड जनरेशन टूल्स

अब एक और डेवलपर टूल का समर्थन करने के लिए जोड़ा गया है - जीएनयू एंबेडेड टूलचिन।

जीएनयू एंबेडेड टूलचेन जीएनयू कंपाइलर संग्रह के आधार पर आर्म से संकलक का एक संग्रह है। पहली आधिकारिक रिलीज 2012 में हुई थी, और तब से यह परियोजना जीसीसी के साथ मिलकर विकसित हो रही है।

जीएनयू एंबेडेड टूलचेन का मुख्य उद्देश्य नंगे धातु पर चलने वाले कोड को उत्पन्न करना है, अर्थात, ऑपरेटिंग सिस्टम के रूप में सीधे इंटरलेयर के बिना प्रोसेसर पर। पैकेज में C और C ++, कोडांतरक, GNU बिनुटिल्स उपयोगिताओं का एक सेट और न्यूलिब लाइब्रेरी के लिए कंपाइलर शामिल हैं । सभी घटकों के लिए स्रोत कोड पूरी तरह से खुला है और जीएनयू जीपीएल के तहत लाइसेंस प्राप्त है। आधिकारिक साइट से आप विंडोज, लिनक्स और मैकओएस के लिए संस्करण डाउनलोड कर सकते हैं।

Mbed OS

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

यद्यपि इस लेख का मुख्य उद्देश्य GNU एंबेडेड टूलकिन के लिए समर्थन के बारे में बात करना है, इसके बारे में बहुत कुछ लिखना मुश्किल है। इसके अलावा, हमारे लेखों के पाठक शायद कुछ दिलचस्प त्रुटियों के वर्णन की प्रतीक्षा कर रहे हैं। ठीक है, चलो उनकी अपेक्षाओं को धोखा न दें और विश्लेषक को ओएस ओएस परियोजना पर चलाएं। यह एक खुला स्रोत ऑपरेटिंग सिस्टम है जिसे आर्म की सहायता से विकसित किया गया है।

आधिकारिक वेबसाइट: https://www.mbed.com/

स्रोत कोड: https://github.com/ARMmbed/mbed-os

Mbed OS पर विकल्प दुर्घटना से नहीं गिरा, यहां बताया गया है कि लेखक परियोजना का वर्णन कैसे करते हैं:

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

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

त्रुटियों

Mbed OS कोड के सत्यापन के दौरान, PVS-Studio विश्लेषक ने 693 चेतावनियाँ दीं, जिनमें से 86 उच्च प्राथमिकता के साथ थीं। मैं उन सभी पर विस्तार से विचार नहीं करूंगा, खासकर जब से उनमें से कई दोहराए गए हैं या विशेष रुचि के नहीं हैं। उदाहरण के लिए, विश्लेषक ने समान कोड टुकड़ों से संबंधित बहुत सी चेतावनियां V547 (अभिव्यक्ति हमेशा सही / गलत है) उत्पन्न की । गलत और निर्बाध प्रतिक्रियाओं की संख्या को कम करने के लिए विश्लेषक को कॉन्फ़िगर किया जा सकता है, लेकिन एक लेख लिखते समय यह कार्य निर्धारित नहीं किया गया था। जो लोग इच्छा करते हैं, वे इस तरह के कॉन्फ़िगरेशन का एक उदाहरण " पीएफएस-स्टूडियो विश्लेषक का उपयोग करके ईएफएल कोर लाइब्रेरीज़ उदाहरण, 10-15% झूठी सकारात्मक " लेख में वर्णित एक उदाहरण देख सकते हैं।

लेख के लिए, मैंने विश्लेषक के संचालन को प्रदर्शित करने के लिए कुछ दिलचस्प त्रुटियों का चयन किया।

स्मृति लीक

चलो सी और सी ++ में त्रुटियों के सामान्य वर्ग के साथ शुरू करते हैं - मेमोरी लीक।

विश्लेषक चेतावनी: V773 CWE-401 समारोह 'read_buf' पॉइंटर जारी किए बिना बाहर किया गया था। एक स्मृति रिसाव संभव है। cfstore_test.c 565

int32_t cfstore_test_init_1(void) { .... read_buf = (char*) malloc(max_len); if(read_buf == NULL) { CFSTORE_ERRLOG(....); return ret; } .... while(node->key_name != NULL) { .... ret = drv->Create(....); if(ret < ARM_DRIVER_OK){ CFSTORE_ERRLOG(....); return ret; // <= } .... free(read_buf); return ret; } 

गतिशील स्मृति के साथ काम करते समय क्लासिक स्थिति। मॉलोक- आवंटित बफर का उपयोग केवल फ़ंक्शन के अंदर किया जाता है और बाहर निकलने से पहले मुक्त किया जाता है। समस्या यह है कि यदि फ़ंक्शन जल्दी काम करना बंद कर देता है तो ऐसा नहीं होता है। यदि ब्लॉक में समान कोड नोट करें। सबसे अधिक संभावना है, लेखक ने शीर्ष टुकड़े की नकल की और एक मुफ्त कॉल जोड़ना भूल गया।

पिछले एक के समान एक और उदाहरण।

विश्लेषक चेतावनी: V773 CWE-401 समारोह 'इंटरफ़ेस' पॉइंटर जारी किए बिना बाहर निकल गया था। एक स्मृति रिसाव संभव है। nanostackemacinterface.cpp 204

 nsapi_error_t Nanostack::add_ethernet_interface( EMAC &emac, bool default_if, Nanostack::EthernetInterface **interface_out, const uint8_t *mac_addr) { .... Nanostack::EthernetInterface *interface; interface = new (nothrow) Nanostack::EthernetInterface(*single_phy); if (!interface) { return NSAPI_ERROR_NO_MEMORY; } nsapi_error_t err = interface->initialize(); if (err) { return err; // <= } *interface_out = interface; return NSAPI_ERROR_OK; } 

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

Memset

मेमसेट फ़ंक्शन का उपयोग अक्सर त्रुटियों की ओर जाता है, इससे जुड़ी समस्याओं के उदाहरण लेख " सी / सी ++ दुनिया में सबसे खतरनाक फ़ंक्शन " में मिल सकते हैं।

निम्नलिखित विश्लेषक चेतावनी पर विचार करें:

V575 CWE-628 'मेमसेट' फ़ंक्शन '0' तत्वों को प्रोसेस करता है। तीसरे तर्क का निरीक्षण करें। mbed_error.c 282

 mbed_error_status_t mbed_clear_all_errors(void) { .... //Clear the error and context capturing buffer memset(&last_error_ctx, sizeof(mbed_error_ctx), 0); //reset error count to 0 error_count = 0; .... } 

प्रोग्रामर ने last_error_ctx संरचना द्वारा कब्जा की गई मेमोरी को रीसेट करने का इरादा किया, लेकिन दूसरे और तीसरे तर्क को मिलाया। नतीजतन, 0 बाइट्स आकार आकार (mbed_error_ctx) से भरे हुए हैं।

ठीक वही त्रुटि सौ लाइनों के ऊपर मौजूद है:

V575 CWE-628 'मेमसेट' फ़ंक्शन '0' तत्वों को प्रोसेस करता है। तीसरे तर्क का निरीक्षण करें। mbed_error.c 123

बिना लूप में बिना शर्त 'रिटर्न ’स्टेटमेंट

विश्लेषक चेतावनी: एक पाश के भीतर V612 CWE-670 एक बिना शर्त 'वापसी'। thread_network_data_storage.c 2348

 bool thread_nd_service_anycast_address_mapping_from_network_data ( thread_network_data_cache_entry_t *networkDataList, uint16_t *rlocAddress, uint8_t S_id) { ns_list_foreach(thread_network_data_service_cache_entry_t, curService, &networkDataList->service_list) { // Go through all services if (curService->S_id != S_id) { continue; } ns_list_foreach(thread_network_data_service_server_entry_t, curServiceServer, &curService->server_list) { *rlocAddress = curServiceServer->router_id; return true; // <= } } return false; } 

इस स्निपेट में, ns_list_foreach वह मैक्रो है जो स्टेटमेंट के लिए विस्तारित होता है। आंतरिक लूप उस पंक्ति के तुरंत बाद वापस आने के लिए एक से अधिक पुनरावृत्ति नहीं करता है, जिसमें फ़ंक्शन के आउटपुट पैरामीटर को पंक्तिबद्ध किया जाता है। शायद यह कोड इरादा के अनुसार काम करता है, लेकिन आंतरिक लूप का उपयोग इस संदर्भ में अजीब लगता है। सबसे अधिक संभावना है, rlocAddress आरंभीकरण और फ़ंक्शन से बाहर निकलना हालत से किया जाना चाहिए, या आप आंतरिक लूप से छुटकारा पा सकते हैं।

शर्तों में त्रुटियां

जैसा कि मैंने ऊपर कहा, विश्लेषक ने निर्बाध रूप से वी 547 चेतावनी की एक बड़ी संख्या उत्पन्न की , इसलिए मैंने उन्हें धाराप्रवाह अध्ययन किया और लेख के लिए केवल दो मामले लिखे।

V547 CWE-570 एक्सप्रेशन 'pcb-> state == LISTEN' हमेशा गलत होता है। lwip_tcp.c 689

 enum tcp_state { CLOSED = 0, LISTEN = 1, .... }; struct tcp_pcb * tcp_listen_with_backlog_and_err(struct tcp_pcb *pcb, u8_t backlog, err_t *err) { .... LWIP_ERROR("tcp_listen: pcb already connected", pcb->state == CLOSED, res = ERR_CLSD; goto done); /* already listening? */ if (pcb->state == LISTEN) { // <= lpcb = (struct tcp_pcb_listen*)pcb; res = ERR_ALREADY; goto done; } .... } 

विश्लेषक मानता है कि स्थिति पीसीबी-> राज्य == लिस्टेन हमेशा गलत है, आइए देखें कि क्यों।

यदि कथन से पहले, LWIP_ERROR मैक्रो का उपयोग किया जाता है , जो ऑपरेशन के अपने तर्क से, मुखर जैसा दिखता है । उनका विज्ञापन इस तरह दिखता है:

 #define LWIP_ERROR(message, expression, handler) do { if (!(expression)) { \ LWIP_PLATFORM_ERROR(message); handler;}} while(0) 

यदि स्थिति झूठी है, तो मैक्रो एक त्रुटि की रिपोर्ट करता है और हैंडलर पैरामीटर के माध्यम से पारित कोड को निष्पादित करता है, इस कोड के टुकड़े में गोटो का उपयोग करके बिना शर्त कूद होता है।

इस उदाहरण में, स्थिति 'पीसीबी-> राज्य == बंद' की जाँच की जाती है, अर्थात् , किए गए लेबल पर संक्रमण तब होता है जब पीसीबी-> राज्य का कोई अन्य मूल्य होता है। यदि LWIP_ERROR को कॉल करने के बाद स्टेटमेंट , LISTEN के लिए pcb-> स्टेट चेक करता है, लेकिन यह शर्त कभी पूरी नहीं होती है, क्योंकि इस लाइन पर स्टेट में केवल CLOSED वैल्यू हो सकती है।

शर्तों से संबंधित एक और चेतावनी पर विचार करें: V517 CWE-570 'if (A) {...} का उपयोग अगर (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइनें: 62, 65. libdhcpv6_server.c 62

 static void libdhcpv6_address_generate(....) { .... if (entry->linkType == DHCPV6_DUID_HARDWARE_EUI64_TYPE) // <= { memcpy(ptr, entry->linkId, 8); *ptr ^= 2; } else if (entry->linkType == DHCPV6_DUID_HARDWARE_EUI64_TYPE)// <= { *ptr++ = entry->linkId[0] ^ 2; *ptr++ = entry->linkId[1]; .... } } 

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

खुद की अभिव्यक्ति

आइए एक मजेदार कोड कोड देखें।

विश्लेषक चेतावनी: V607 मालिक की अभिव्यक्ति 'और search_response_tlv'। thread_discovery.c 562

 static int thread_discovery_response_send( thread_discovery_class_t *class, thread_discovery_response_msg_t *msg_buffers) { .... thread_extension_discover_response_tlv_write( &discover_response_tlv, class->version, linkConfiguration->securityPolicy); .... } 

अब आइए मैक्रो घोषणापत्र थ्रेड पर एक नज़र डालते हैं_स्टेंशन_डिस्कवर_प्रोसेस_tlv_write :

 #define thread_extension_discover_response_tlv_write \ ( data, version, extension_bit)\ (data) 

मैक्रो को डेटा तर्क में विस्तारित किया जाता है, अर्थात, प्रीप्रोसेसिंग के बाद थ्रेड_डिस्कोवरी_प्रतिसाद_सेंड फ़ंक्शन के अंदर इसकी कॉल एक अभिव्यक्ति (और search_response_tlv ) में बदल जाती है।

मेरी कोई टिप्पणी नहीं है। यह शायद कोई गलती नहीं है, लेकिन इस तरह का एक कोड मुझे हमेशा चित्र में छवि के समान स्थिति में रखता है :)।

निष्कर्ष

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: यूरी मिनाएव। PVS-Studio अब GNU आर्म एंबेडेड टूलचिन का समर्थन करता है ।