C (أو أي) الأداء الحتمي للمجمعين
https://stackoverflow.com/questions/60547
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أثناء العمل في مشروع حديث، زارني أحد ممثلي ضمان الجودة للعملاء، وسألني سؤالاً لم أفكر فيه من قبل:
كيف تعرف أن المترجم الذي تستخدمه يقوم بإنشاء كود الجهاز الذي يتطابق تمامًا مع وظيفة كود c وأن المترجم محدد تمامًا؟
لم يكن لدي أي رد على هذا السؤال لأنني كنت دائمًا أعتبر المترجم أمرًا مفروغًا منه.فهو يأخذ الكود ويطلق كود الآلة.كيف يمكنني المتابعة واختبار أن المترجم لا يضيف فعليًا وظائف لم أطلبها؟أو حتى تنفيذ التعليمات البرمجية بشكل أكثر خطورة بطريقة مختلفة قليلاً عما أتوقعه؟
أدرك أن هذه ربما لا تمثل مشكلة بالنسبة للجميع، وبالفعل قد تكون الإجابة فقط..."لقد تجاوزت البرميل وتعاملت معه".ومع ذلك، عند العمل في بيئة مضمنة، فإنك تثق بالمترجم الخاص بك ضمنيًا.كيف يمكنني أن أثبت لنفسي ولضمان الجودة أنني على حق في القيام بذلك؟
المحلول
من أجل السلامة، تتطلب وكالات اعتماد التطبيقات المضمنة الهامة استيفاء متطلبات "إثبات الاستخدام" للمترجم.عادةً ما تكون هناك متطلبات معينة (مثل "ساعات العمل") التي يجب الوفاء بها وإثباتها من خلال الوثائق التفصيلية.ومع ذلك، فإن معظم الأشخاص إما لا يستطيعون أو لا يريدون تلبية هذه المتطلبات لأنها قد تكون صعبة للغاية خاصة في مشروعك الأول مع هدف/مترجم جديد.
أحد الأساليب الأخرى هو عدم الثقة في مخرجات المترجم على الإطلاق.يجب تغطية أي أوجه قصور في المترجم وحتى المعتمد على اللغة (الملحق G لمعيار C-90، أي شخص؟) من خلال مجموعة صارمة من التحليل الثابت واختبار الوحدة والتغطية بالإضافة إلى الاختبار الوظيفي اللاحق.
معيار مثل ميسرا-C يمكن أن يساعد في تقييد إدخال المترجم إلى مجموعة فرعية "آمنة" من لغة C.هناك طريقة أخرى تتمثل في تقييد إدخال المترجم على مجموعة فرعية من اللغة واختبار مخرجات المجموعة الفرعية بأكملها.إذا كان تطبيقنا مبنيًا فقط على مكونات من المجموعة الفرعية، فمن المفترض أن نعرف ما ستكون عليه مخرجات المترجم.عادة ما يتم ذلك عن طريق "تأهيل المترجم".
الهدف من كل هذا هو أن نكون قادرين على الإجابة على سؤال ممثل ضمان الجودة بـ "نحن لا نعتمد فقط على حتمية المترجم ولكن هذه هي الطريقة التي نثبت بها ذلك...".
نصائح أخرى
يمكنك تطبيق هذه الحجة على أي مستوى:هل تثق بمكتبات الطرف الثالث؟هل تثق في نظام التشغيل؟هل تثق في المعالج؟
من الأمثلة الجيدة على سبب كون هذا مصدر قلق صحيح بالطبع، هو الطريقة التي وضع بها كين طومسون بابًا خلفيًا في برنامج "تسجيل الدخول" الأصلي ...وقمت بتعديل برنامج التحويل البرمجي C بحيث أنه حتى لو قمت بإعادة ترجمة تسجيل الدخول، فإنك لا تزال تحصل على الباب الخلفي.انظر الى هذا نشر لمزيد من التفاصيل.
وقد أثيرت أسئلة مماثلة حول خوارزميات التشفير - كيف نعرف أنه لا يوجد باب خلفي في DES يمكن لوكالة الأمن القومي أن تتطفل عليه؟
في النهاية، عليك أن تقرر ما إذا كنت تثق في البنية التحتية التي تبني عليها بدرجة كافية حتى لا تقلق بشأنها، وإلا فسيتعين عليك البدء في تطوير شرائح السيليكون الخاصة بك!
أنت تعرف عن طريق الاختبار.عندما تقوم بالاختبار، فإنك تختبر كلاً من الكود والمترجم.
ستجد أن احتمالات ارتكابك أنت أو كاتب المترجم لخطأ أقل بكثير من احتمالات ارتكابك خطأ إذا كتبت البرنامج المعني في بعض لغات التجميع.
هناك الدعاوى التحقق من صحة المترجم المتاحة.
الذي أتذكره هو "الدائمة".
عندما عملت على مترجم C لمعالج SOC مضمن، كان علينا التحقق من صحة المترجم مقابل هذه الدعوى وبدلتين أخريين للتحقق من الصحة (نسيت اسمهما).كان التحقق من صحة المترجم إلى مستوى معين من المطابقة لبدلات الاختبار هذه جزءًا من العقد.
كل ذلك يتلخص في الثقة.هل يثق عميلك في أي مترجم؟استخدم ذلك، أو على الأقل قارن رمز الإخراج بين كودك ورمزهم.
إذا كانوا لا يثقون بأي منها، فهل هناك تطبيق مرجعي للغة؟هل يمكنك إقناعهم بالثقة فيه؟ثم قارن ما لديك بالمرجع أو استخدم المرجع.
كل هذا على افتراض أنك تتحقق فعليًا من الكود الفعلي الذي تحصل عليه من البائع/المزود وأنك تتحقق من عدم العبث بالمترجم، وهو ما يجب أن يكون الخطوة الأولى.
على أي حال، لا يزال هذا يترك السؤال حول كيفية التحقق من المترجم، دون الحاجة إلى مراجع، من البداية.من المؤكد أن هذا يبدو وكأنه الكثير من العمل ويتطلب تعريفًا للغة، وهو ما لا يتوفر دائمًا، وأحيانًا يكون التعريف هو المترجم.
كيف تعرف أن المترجم الذي تستخدمه يقوم بإنشاء كود الجهاز الذي يتطابق تمامًا مع وظيفة كود c وأن المترجم محدد تمامًا؟
لا تفعل ذلك، ولهذا السبب تختبر الثنائي الناتج، وتتأكد من شحن نفس الثنائي الذي اختبرته.ولماذا عند إجراء تغييرات "بسيطة" على البرنامج، فإنك تقوم باختبار الانحدار للتأكد من عدم تعطل أي من الوظائف القديمة.
البرنامج الوحيد الذي حصلت على اعتماده هو إلكترونيات الطيران.إن شهادة إدارة الطيران الفيدرالية (FAA) ليست صارمة بما يكفي لإثبات أن البرنامج يعمل بشكل صحيح، وفي الوقت نفسه تجبرك على القفز عبر قدر معين من العقبات.تكمن الحيلة في تنظيم "العملية" الخاصة بك بحيث تعمل على تحسين الجودة قدر الإمكان، مع أقل قدر ممكن من القفزات الخارجية التي يمكنك الهروب منها.لذا فإن أي شيء تعرفه لا قيمة له ولن تجد فيه أخطاء فعلية، فمن المحتمل أن تتهرب منه.وأي شيء تعرفه يجب عليك فعله لأنه سوف ابحث عن الأخطاء التي لم تطلبها إدارة الطيران الفيدرالية (FAA) صراحةً، فأفضل رهان لك هو تحريف الكلمات حتى يبدو الأمر وكأنك تمنح إدارة الطيران الفيدرالية/مسؤولي ضمان الجودة ما طلبوه.
هذا في الواقع ليس غير أمين كما جعلته يبدو، بشكل عام تهتم إدارة الطيران الفيدرالية أكثر بكونك ضميريًا وواثقًا من أنك محاولة للقيام بعمل جيد، من ما تفعله بالضبط.
يمكن العثور على بعض الذخيرة الفكرية في Crosstalk، وهي مجلة لمهندسي البرمجيات الدفاعية.هذا السؤال هو الشيء الذي يقضون عليه ساعات طويلة من الاستيقاظ. http://www.stsc.hill.af.mil/crosstalk/2006/08/index.html (إذا تمكنت من العثور على ملاحظاتي القديمة من مشروع قديم، فسأعود إلى هنا...)
لا يمكنك أبدًا أن تثق بالمترجمين بشكل كامل، حتى المترجمين الموصى بهم بشدة.يمكنهم إصدار تحديث يحتوي على خطأ، ويقوم الكود الخاص بك بتجميع نفس الشيء.تتفاقم هذه المشكلة عند تحديث التعليمات البرمجية القديمة باستخدام مترجم عربات التي تجرها الدواب، وإجراء الاختبار وشحن البضائع فقط ليتصل بك العميل بعد 3 أشهر لإبلاغك بالمشكلة.
يعود الأمر كله إلى الاختبار، وإذا كان هناك شيء واحد تعلمته فهو الاختبار الدقيق بعد أي تغيير غير تافه.إذا كان من المستحيل العثور على المشكلة، فقم بإلقاء نظرة على المجمّع المترجم وتأكد من قيامه بما يجب عليه القيام به.
لقد وجدت في عدة مناسبات أخطاء في المترجم.ذات مرة كان هناك خطأ حيث سيتم زيادة متغيرات 16 بت ولكن بدون ترحيل وفقط إذا كان المتغير 16 بت جزءًا من بنية خارجية محددة في ملف رأس.
...أنت تثق بالمترجم الخاص بك ضمنيًا
ستتوقف عن القيام بذلك في المرة الأولى التي تصادف فيها خطأ في برنامج التحويل البرمجي.؛-)
ولكن في النهاية هذا هو الغرض من الاختبار.لا يهم نظام الاختبار الخاص بك كيفية وصول الخلل إلى منتجك في المقام الأول، كل ما يهم هو أنه لم يجتاز نظام الاختبار الشامل الخاص بك.
حسنًا..لا يمكنك أن تقول ببساطة أنك تثق في مخرجات المترجم الخاص بك - خاصة إذا كنت تعمل مع التعليمات البرمجية المضمنة.ليس من الصعب العثور على اختلافات بين التعليمات البرمجية التي تم إنشاؤها عند تجميع نفس التعليمات البرمجية مع مترجمين مختلفين.هذا هو الحال لأن معيار C نفسه فضفاض للغاية.يمكن تنفيذ العديد من التفاصيل بشكل مختلف بواسطة مترجمين مختلفين دون كسر المعيار.كيف نتعامل مع هذه الأشياء؟نحن نتجنب التركيبات المعتمدة على المترجم كلما أمكن ذلك.قد نتعامل معها عن طريق اختيار مجموعة فرعية أكثر أمانًا من لغة C مثل ميسرا-C كما ذكر سابقا من قبل المستخدم cschol.نادرًا ما أضطر إلى فحص الكود الذي أنشأه المترجم ولكن هذا حدث لي أيضًا في بعض الأحيان.لكنك، في النهاية، تعتمد على اختباراتك للتأكد من أن الكود يعمل على النحو المنشود.
هل هناك خيار أفضل هناك؟بعض الناس يزعمون أن هناك.الخيار الآخر هو كتابة الكود الخاص بك سبارك/آدا.لم أكتب أبدًا تعليمات برمجية في SPARK ولكن ما أفهمه هو أنه لا يزال يتعين عليك ربطه بالإجراءات المكتوبة بلغة C والتي من شأنها أن تتعامل مع الأشياء "المعدنية".إن جمال SPARK/Ada هو أنك تضمن تمامًا أن الكود الذي تم إنشاؤه بواسطة أي مترجم سيكون دائمًا هو نفسه.لا يوجد أي غموض على الإطلاق.علاوة على ذلك، تتيح لك اللغة إضافة تعليقات توضيحية إلى الكود مع توضيحات حول كيفية عمل الكود.ستستخدم مجموعة أدوات SPARK هذه التعليقات التوضيحية لإثبات رسميًا أن الكود المكتوب يقوم بالفعل بما وصفته التعليقات التوضيحية.لقد قيل لي أنه بالنسبة للأنظمة المهمة، يعد SPARK/Ada رهانًا جيدًا جدًا.لم أحاول ذلك بنفسي بالرغم من ذلك.
أنت لا تعرف على وجه اليقين أن المترجم سيفعل بالضبط ما تتوقعه.والسبب هو ذلك بالطبع المترجم هو قطعة من البرمجيات, ، وبالتالي فهو عرضة للأخطاء.
يتمتع مؤلفو المترجمات بميزة العمل وفقًا لمواصفات عالية الجودة، بينما يتعين على بقيتنا اكتشاف ما نقوم بصنعه أثناء تقدمنا.ومع ذلك، مواصفات المترجم أيضًا تحتوي على أخطاء، وأجزاء معقدة ذات تفاعلات دقيقة.لذلك، ليس من السهل معرفة ما يجب أن يفعله المترجم.
ومع ذلك، بمجرد أن تقرر ما تعتقد أنه يعنيه مواصفات اللغة، يمكنك كتابة اختبار آلي جيد وسريع لكل الفروق الدقيقة.هذا هو المكان الذي تتمتع فيه الكتابة المترجمة بميزة كبيرة مقارنة بكتابة أنواع أخرى من البرامج:في الاختبار.يصبح كل خطأ حالة اختبار تلقائية، ويمكن لمجموعة الاختبار أن تكون شاملة للغاية.لدى بائعي المترجمات ميزانية أكبر بكثير للاستثمار في التحقق من صحة المترجم مما لديك (لديك بالفعل وظيفة يومية، أليس كذلك؟).
ماذا يعني هذا بالنسبة لك؟هذا يعني أنك بحاجة إلى أن تكون منفتحًا على احتمالات وجود أخطاء في المترجم الخاص بك، ولكن من المحتمل أنك لن تجد أيًا منها بنفسك.
سأختار بائع مترجم ليس من المرجح أن يتوقف عن العمل في أي وقت قريب، ولديه تاريخ من الجودة العالية في مترجميه، والذي أثبت قدرته على خدمة (تصحيح) منتجاته.يبدو أن المترجمين يصبحون أكثر دقة مع مرور الوقت، لذلك سأختار واحدًا مضى عليه عقد أو عقدين تقريبًا.
ركز انتباهك على الحصول على التعليمات البرمجية الخاصة بك بشكل صحيح. إذا كان واضحة وبسيطة, ، ثم عندما يفعل إذا أصابك خطأ في المترجم، فلن تضطر إلى التفكير مليًا لتقرر أين تكمن المشكلة. اكتب اختبارات الوحدة الجيدة, ، مما سيضمن أن الكود الخاص بك يفعل ما تتوقعه منه.
حاول اختبار الوحدة.
إذا لم يكن ذلك كافيًا، فاستخدم مترجمين مختلفين وقارن نتائج اختبارات الوحدة الخاصة بك.قارن مخرجات التتبع، وقم بإجراء اختباراتك في جهاز افتراضي، واحتفظ بسجل للقرص والإدخال/الإخراج للشبكة، ثم قارنها.
أو اقترح كتابة المترجم الخاص بك وإخبارهم بتكلفة ذلك.
أكثر ما يمكنك التصديق عليه بسهولة هو أنك تستخدم مترجمًا غير مُتلاعب به من الموفر X.إذا كانوا لا يثقون بالمزود X، فهذه مشكلتهم (إذا كان X جديرًا بالثقة إلى حد معقول).إذا كانوا لا يثقون في أي مزود مترجم، فهم غير معقولين على الإطلاق.
الإجابة على سؤالهم:أتأكد من أنني أستخدم مترجمًا غير معطوب من X من خلال هذه الوسائل.يتمتع X بسمعة طيبة، بالإضافة إلى أن لدي مجموعة رائعة من الاختبارات التي توضح أن تطبيقنا يتصرف كما هو متوقع.
كل شيء آخر بدأ في فتح علبة الديدان.عليك أن تتوقف في مكان ما، كما يقول روب.
في بعض الأحيان تحصل على تغييرات سلوكية عندما تطلب مستويات قوية من التحسين.
والتحسين وأرقام الفاصلة العائمة؟انسى ذلك!
بالنسبة لمعظم برامج تطوير البرامج (مثل تطبيقات سطح المكتب)، ربما تكون الإجابة هي أنك لا تعرف ولا تهتم.
في الأنظمة ذات الأهمية الحيوية للسلامة (مثل محطات الطاقة النووية وإلكترونيات الطيران التجارية). يفعل سوف تطلب منك وكالات الرعاية والتنظيم إثبات ذلك.ومن خلال تجربتي، يمكنك القيام بذلك بإحدى طريقتين:
- استخدم مترجمًا مؤهلًا، حيث تعني كلمة "مؤهل" أنه تم التحقق منه وفقًا للمعايير التي حددتها الهيئة التنظيمية.
- إجراء تحليل رمز الكائن.بشكل أساسي، تقوم بتجميع جزء من التعليمات البرمجية المرجعية ثم تقوم بتحليل المخرجات يدويًا لإثبات أن المترجم لم يقم بإدراج أي تعليمات لا يمكن إرجاعها إلى التعليمات البرمجية المصدر الخاصة بك.
تحصل على ما كتبه ديكسترا.
حدد مترجمًا تم التحقق منه رسميًا، مثل مترجم Compcert C.
- سيؤدي تغيير مستوى تحسين المترجم إلى تغيير الإخراج.
- قد تؤدي التغييرات الطفيفة في إحدى الوظائف إلى جعل المترجم مضمنًا أو لم يعد مضمّنًا في الوظيفة.
- قد تؤدي التغييرات التي يتم إجراؤها على المترجم (إصدارات دول مجلس التعاون الخليجي على سبيل المثال) إلى تغيير الإخراج
- قد تكون بعض وظائف المكتبة جوهرية (أي تنبعث من التجميع الأمثل) بينما لا تكون وظائف أخرى كذلك.
والخبر السار هو أنه بالنسبة لمعظم الأشياء لا يهم كثيرًا.عندما يحدث ذلك، قد ترغب في التفكير في التجميع إذا كان الأمر مهمًا حقًا (على سبيل المثال، في ISR).
إذا كنت قلقًا بشأن تعليمات برمجية غير متوقعة للجهاز والتي لا تؤدي إلى نتائج مرئية، فمن المحتمل أن تكون الطريقة الوحيدة هي الاتصال ببائع المترجم للحصول على شهادة من نوع ما ترضي عميلك.
وإلا فستعرف نفس ما تعرفه عن الأخطاء الموجودة في التعليمات البرمجية الخاصة بك - الاختبار.
يمكن أن يكون كود الآلة من المترجمين الحديثين مختلفًا إلى حد كبير وغير مفهوم تمامًا بالنسبة للبشر الضعفاء.
أعتقد أنه من الممكن الحد من هذه المشكلة إلى مشكلة التوقف بطريقة ما.
المشكلة الأكثر وضوحًا هي أنه إذا كنت تستخدم نوعًا ما من البرامج لتحليل المترجم وحتميته، فكيف تعرف ذلك لك يتم تجميع البرنامج بشكل صحيح، وينتج النتيجة الصحيحة؟
إذا كنت تستخدم مترجمًا آخر "آمنًا"، فأنا لست متأكدًا.ما أنا متأكد منه هو أن كتابة مترجم من الصفر ربما تكون مهمة أسهل.
حتى المترجم المؤهل أو المعتمد يمكن أن يؤدي إلى نتائج غير مرغوب فيها.اجعل الكود الخاص بك بسيطًا واختبر، اختبر، اختبر.ذلك أو المرور عبر رمز الجهاز يدويًا مع عدم السماح بأي خطأ بشري.بالإضافة إلى نظام التشغيل أو أي بيئة تعمل عليها (يفضل عدم وجود نظام تشغيل، فقط البرنامج الخاص بك).
لقد تم حل هذه المشكلة في بيئات المهام الحرجة منذ بدء تشغيل البرامج والمترجمين.كما يعلم أيضًا العديد من الآخرين الذين استجابوا.كل صناعة لها قواعدها الخاصة بدءًا من المترجمين المعتمدين وحتى أسلوب البرمجة (يجب عليك دائمًا البرمجة بهذه الطريقة، وعدم استخدام هذا أو ذاك أو ذاك)، والكثير من الاختبارات ومراجعة النظراء.التحقق من كل مسار تنفيذ، وما إلى ذلك.
إذا لم تكن في واحدة من تلك الصناعات، فإنك تحصل على ما تحصل عليه.برنامج تجاري على نظام تشغيل COTS على أجهزة COTS.سوف تفشل، وهذا هو الضمان.
إذا كنت قلقا بشأن ضارة الأخطاء الموجودة في المترجم، إحدى التوصيات (IIRC، أحد متطلبات NSA لبعض المشاريع) هي أن المترجم الثنائي يسبق كتابة التعليمات البرمجية.على الأقل تعلم أن لا أحد لديه وأضاف الأخطاء المستهدفة لك برنامج.
