أداة التحليل الثابت للكشف عن فواصل ABI في C ++

Question

ليس من الصعب للغاية كسر التوافق الثنائي للخلف لمكتبة DSO/مشتركة مع واجهة C ++. ومع ذلك ، هل هناك أداة تحليل ثابتة ، يمكن أن تساعد في اكتشاف فترات راحة ABI هذه ، إذا تم إعطاؤها مجموعتين مختلفتين من ملفات الرأس: تلك الموجودة في حالة DSO السابقة وموضوعات الحالة الحالية (وربما DSOs أيضًا)؟ كل من اقتراحات المنتجات المجانية والتجارية مرحب بها.

إذا تمكنت أيضًا من تحذير الممارسات السيئة ، مثل الوظائف المضمنة ومعلمات الوظائف الافتراضية في واجهات DSO ، فسيكون ذلك رائعًا.

Answer 1

أفترض أنك على دراية بهذا البرنامج التعليمي: مشاكل التوافق الثنائي مع C ++, ، ان لم اقرأها!

سمعت عن هذه الأداة:http://ispras.linuxbase.org/index.php/abi_compliance_checker, ، ومع ذلك لم يتم اختبارها أو تستخدم واحدة ، لذلك ليس لديك رأي.

أيضا هذا قد يثير اهتمامك: إنشاء مكتبة مع ABI متوافق مع الخلف التي تستخدم دفعة

Answer 2

ABI-COMPLIANCE CEECKER - أداة للتحقق من التوافق الثنائي/المصدر للخلف لمكتبة C/C ++ المشتركة (DSO):

أداة للتحقق من التوافق الثنائي ومستوى المصدر لمكتبة C/C ++. تتحقق الأداة من ملفات الرأس والمكتبات المشتركة للإصدارات القديمة والجديدة وتحليل التغييرات في API و ABI (ABI = API+برنامج التحويل البرمجي ABI) التي قد تكسر التوافق الثنائي و/أو المصدر: التغييرات في مكدس الاتصال ، تغييرات الطاولة V ، الرموز التي تمت إزالتها ، أعيد تسميته الحقول ، إلخ.

انا اتحقق - C واجهة ABI/API Checker:

أداة للتحقق بشكل ثابت من واجهات C لتغييرات API و ABI. يجب اكتشاف جميع التغييرات في التصريحات التي يمكن أن تسبب تغييرات ABI ، إلى جانب معظم تغييرات API. يهدف ICheck للاستخدام مع المكتبات ، كوسيلة لمنع انجراف ABI.

shlib-compat - ABI Compatibility Checker للمكتبات المشتركة مع إصدار الرمز:

يستخدم SHLIB-COMPAT رموز تصحيح الأخطاء القزم لإعادة إنشاء ومقارنة تعريفات الرموز المصدرة ، بما في ذلك وسيطات الوظائف والأنواع الهيكلية.

كما قد تكون مهتمًا بـ Linux Upstream Tracker و Linux ABI Tracker خدمات. كلاهما مدعوم من أداة فحص ABI-Confliance.

Answer 3

أتذكر في العمل الذين استخدموه GCC XML لاختبار التوافق الثنائي. في الأساس ما تفعله هو توليد تمثيل XML لشجرة كائن التحويل البرمجي. تقول النظرية أنه إذا كان XML مكافئًا ، فقد تم الحفاظ على التوافق الثنائي.

Answer 4

الطريقة الآمنة الوحيدة للقيام بذلك هي تصدير مكتبتك باستخدام واجهة C. مكتبة C ++ متوافقة فقط مع برنامج التحويل البرمجي الوحيد الذي تستخدمه لتجميعه.

Answer 5

ملكنا C ++ الاختلاف الذكي تقارن الأداة بين ملفين المصدر والتقارير اختلافات من حيث هياكل اللغة (المعرفات ، التعبيرات ، العبارات ، ...) وإجراءات التحرير المعقولة (إدراج ، حذف ، تحرك ، نسخ ، استبدال الهوية ، ...).

لا يجيب على سؤال ABI مباشرة ، لكن المعلومات التي توفرها قد تكون مفيدة للغاية. مثال تمت مناقشته في إجابة أخرى هو تغيير نوع العودة من بنية {a ، b} إلى بنية {ب ، أ). سيبلغ SmartDifferencer ذلك أ تم نقلها. (ملاحظة: ستقوم أداة Diff العادية بالإبلاغ عن تغيير هذا الخط الذي يحتوي على تعريف الهيكل ، لذلك يمكنك الحصول على نفس المعلومات ، لكن SmartDifference سوف يتجاهل التغييرات في المساحات البيضاء/التخطيط والتعليقات ، أيضًا ، مما يؤدي إلى ضوضاء مفاهيمية أقل).

ما لا سيبلغه أي من هذه الأدوات هو تغيير تعريف typedef ، فهو في ملف رأس آخر. ولكن من المفترض أن يقارن المرء جميع ملفات الرأس المعنية. إذا كنت لا ترغب في القيام بذلك يدويًا ، فيجب أن تتضمن أي أداة قيد الاستخدام بشكل أساسي محلل C ++ الكامل ، وحدد الأسماء ، ويجب أن تقارن إعلانات التكافؤ. اقترح ملصق آخر إلى حد كبير الإجابة: مقارنة إخراج GCCXML للتعادل. لست متأكدًا من مدى سهولة ذلك في الممارسة ؛ لا يمكن أن يكون فقط "هل الملفات هي نفسها XML بالترتيب؟".

Answer 6

ABI - تعود الواجهة الثنائية للتطبيق إلى الطريقة التي يترجم بها برنامج التحويل البرمجي رمز المصدر إلى الإرشادات المعروفة بالجهاز. يمكن ترجمة سطر المصدر نفسه إلى دفق مختلف من البايتات ، في البرنامج النهائي.

لن يتمكن المحلل الثابت الذي يعمل فوق الكود المصدري من التنبؤ بكيفية ترجمته المترجم. يتم اتخاذ هذا القرار في ترميز المترجم أو الإعدادات. لذلك لا أعتقد أن المحلل الثابت سيكون مفيدًا لك في هذه الحالة.