x86: डेटा-संरेखण दोषों को कैसे पकड़ें (स्पार्क पर उर्फ ​​सिगबस)

Question

क्या i386 पर भी डेटा-संरेखण दोषों को पकड़ना संभव है? शायद i386 विशिष्ट मशीन रजिस्टर या ऐसा कुछ सेट करके।

सोलारिस-स्पार्क पर मुझे इस मामले में एक सिगबस मिल रहा है, लेकिन i386 पर सब कुछ ठीक है।

पर्यावरण:

• 32-बिट अनुप्रयोग
• उबंटू कार्मिक
• जीसीसी/जी ++ v4.4.1

संपादित: यहाँ क्यों है मैं इस पूछ रहा हूँ:

• हमारे आवेदन सिगबस के साथ सोल-स्पार्क पर दुर्घटनाग्रस्त हो जाता है। डीबगिंग के प्रयोजन के लिए मैं अपने i386 प्लेटफ़ॉर्म पर समान व्यवहार करने का प्रयास करूंगा।
• हमारी सोल-स्पार्क मशीन बहुत धीमी है, इसलिए संकलन और डिबगिंग में बहुत समय लगता है। और हमारी i386 मशीन अविश्वसनीय तेज़ है (8 कोर, 32 जी मेमोरी)।
• i386 प्लेटफॉर्म पर भी डेटा-संरेखण दोषों पर प्रदर्शन की लागत है। और इसलिए मैं जहां भी संभव हो डेटा-संरेखण दोषों को ठीक करना चाहता हूं।

Answer 1

वोकिला-ओलिबा के उत्तर पर विस्तार करने के लिए "SOF Mis-aligned pointers on x86." धागा को देखते हुए ऐसा लगता है कि जीसीसी गलत गठबंधन स्मृति पहुंच के साथ कोड उत्पन्न कर सकता है। AFAIK आप पर इसका कोई नियंत्रण नहीं है।

जीसीसी संकलित कोड पर संरेखण जांच सक्षम करना एक बुरा विचार होगा। आपको अच्छा सी कोड के लिए SIGBUS त्रुटियां प्राप्त करने का जोखिम है।

reedited: के बारे में है कि

Answer 2

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

संपादित करें: गलत साबित होने के लिए बहुत खुश हैं।

Answer 3

इस बीच मुझे इस विषय को संबोधित करने वाला इंटेल सीपीयू दस्तावेज़ मिला।

Intel® 64 and IA-32 Architectures Software Developer’s Manual देखें।

यह सब सामान एक साथ रखना मुश्किल लगता है। हालांकि ऐसा लगता है कि यह पूरी तरह असंभव नहीं है। दिलचस्प अध्याय 4.10.5 संरेखण

संपादित (उल्लेख दस्तावेज़ से कुछ गाढ़ा सामग्री) जांच की जा रही है:

पेज 5-60

Interrupt 17 Alignment Check Exception (#AC) 

to enable alignment checking, the following conditions must be true: 

AM flag is set(bit 18 of control regisster CR0) 
AC flag is set (bit 18 of the EFLAGS) 
The CPL is 3 (protected mode or virtual-8086 mode). 

अतिरिक्त - 14.8.2.6 में - मेमोरी कंट्रोलर त्रुटियां का उल्लेख किया गया है। मुझे नहीं पता कि यह केवल दूसरे शब्दों में ही है:

table 14-11, Encoding of MMM and CCCC Sub-Fields 
Address/Command Error AC 011 

Answer 4

मुझे एसओएफ पर एक बहुत ही सरल समाधान मिला है! देखें: Mis-aligned pointers on x86।

int main(int argc, char **argv) 
{ 
# if defined i386 
    /* EDIT: enable AC check */ 
    asm("pushf; " 
    "orl $(1<<18), (%esp); " 
    "popf;"); 
# endif 

    char d[] = "12345678"; /* yep! - causes SIGBUS even on Linux-i386 */ 
    return 0; 
} 

लेकिन मैं कबूल करना चाहिए कि मुझे समझ नहीं आता क्यों काम

चार घ [] = "12345678";

गलत गठबंधन माना जाता है?

संपादित करें:

स्पार्क मशीन पर

[] करने के लिए चार घ असाइनमेंट की लाइन पर कोई SIGBUS है।

Answer 5

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

Answer 6

कई साल बाद: यदि आपके जीसीसी/बजना काफी नया है (जीसीसी 4.9, 3.3 बजना?) आप प्रक्षालक (-fsanitize=undefined) अपरिभाषित व्यवहार के बारे में गलत संरेखित किसी दिए गए मंच पर पहुँचता चेतावनी प्राप्त करने के लिए के साथ अपने कोड का निर्माण करने में सक्षम हो सकता (लेकिन विभिन्न प्लेटफार्मों को ध्यान में रखते हुए अलग-अलग संरेखण की आवश्यकता होती है, विभिन्न कंपाइलर्स अलग-अलग लेआउट आदि चुनेंगे)। विवरण के लिए https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html और https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ देखें।