ليبر أوفيس:تحديد جزء الكود المصدري المسؤول عن الطباعة

Question

أحاول تنفيذ بعض الوظائف الإضافية لعملية طباعة LibreOffice (يجب إضافة بعض المعلومات الخاصة تلقائيًا إلى هوامش كل صفحة مطبوعة).أنا أستخدم RHEL 6.4 مع LibreOffice 4.0.4 وGnome 2.28.

هدفي هو البحث في تدفق البيانات بين LibreOffice ومكونات النظام وتحديد أكواد المصدر المسؤولة عن الطباعة.بعد ذلك سيتعين علي تعديل هذه الأجزاء من التعليمات البرمجية.

الآن أحتاج إلى نصيحة حول طرق البحث عن الكود المصدري.لقد وجدت الكثير من الأدوات ومن وجهة نظري:

1. strace يبدو أن المستوى منخفض جدًا؛
2. gprof يتطلب ثنائيات تمت إعادة ترجمتها باستخدام "-pg" CFLAGS؛ليس لديك أي فكرة عن كيفية القيام بذلك مع LibreOffice؛
3. systemtap يمكن التحقيق في syscalls فقط، أليس كذلك؟
4. callgrind + Gprof2Dot جيدان جدًا معًا ولكنهما يؤديان إلى نتائج غريبة (انظر أدناه)؛

على سبيل المثال هنا هو الرسم البياني للاتصال من callgrind الإخراج مع Gprof2Dot التصور.بدأت callgrind بمثل هذا الأمر:

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes /usr/lib64/libreoffice/program/soffice --writer

وتلقى أربعة ملفات الإخراج:

-rw-------.   1 root  root          0 Jan  9 21:04 callgrind.out.29808
-rw-------.   1 root  root     427196 Jan  9 21:04 callgrind.out.29809
-rw-------.   1 root  root     482134 Jan  9 21:04 callgrind.out.29811
-rw-------.   1 root  root     521713 Jan  9 21:04 callgrind.out.29812

آخر واحد (pid 29812) يتوافق مع تطبيق LibreOffice Writer GUI قيد التشغيل (لقد حددته باستخدام strace و ps aux).ضغطت كنترول+ص وزر موافق.ثم أغلقت التطبيق على أمل رؤية الوظيفة المسؤولة عن طباعة تهيئة العملية في السجلات.

ال callgrind تمت معالجة الإخراج باستخدام أ Gprof2Dot أداة وفقا لهذه الإجابة.لسوء الحظ، لا أستطيع أن أرى في الصورة الإجراءات التي أهتم بها، ولا الرسم البياني للاتصال كما هو.

وسأكون ممتنًا لأية معلومات حول الطريقة الصحيحة لحل مثل هذه المشكلة.شكرًا لك.

Answer 1

الطريقة الصحيحة لحل هذه المشكلة تتذكر أن LibreOffice مفتوح المصدر.يتم توثيق شفرة المصدر بأكمله ويمكنك استعراض الوثائق على docs.libreoffice.org .لا تفعل ذلك بالطريقة الصعبة :)

إلى جانب ذلك، تذكر أن مربع حوار إعداد الطابعة ليس خاصا بليبي، بدلا من ذلك، يتم توفيره بواسطة نظام التشغيل.

Answer 2

ما تريده هو أداة لتحديد كود المصدر محل الاهتمام.يمكن لأدوات تغطية الاختبار (TC) توفير هذه المعلومات.

ما تفعله أدوات TC هو تحديد أجزاء التعليمات البرمجية التي تم تشغيلها، عند ممارسة البرنامج؛فكر في الأمر على أنه تجميع كمجموعة من مناطق التعليمات البرمجية.عادةً ما يتم استخدام أدوات TC جنبًا إلى جنب مع اختبارات (التفاعلية/الوحدة/التكامل/النظام)، لتحديد مدى فعالية الاختبارات.إذا تم تنفيذ كمية صغيرة فقط من التعليمات البرمجية (كما تم اكتشافها بواسطة أداة TC)، فسيتم تفسير الاختبارات على أنها غير فعالة أو غير كاملة؛إذا تمت تغطية نسبة كبيرة، يكون لدى المرء اختبارات جيدة ومبرر معقول لشحن المنتج (على افتراض اجتياز جميع الاختبارات).

ولكن يمكنك استخدام أدوات TC للعثور على التعليمات البرمجية التي تنفذ الميزات.أولاً، عليك إجراء بعض الاختبارات (أو ربما تشغيل البرنامج يدويًا) لممارسة الميزة محل الاهتمام، وجمع بيانات TC.يخبرك هذا بمجموعة التعليمات البرمجية التي تم ممارستها، إذا تم استخدام الميزة؛إنها مبالغة في تقدير الكود الذي يهمك.ثم تقوم بتمرين البرنامج، وتطلب منه القيام ببعض الأنشطة المماثلة، ولكنها لا تمارس الميزة.يحدد هذا مجموعة التعليمات البرمجية التي لا تنفذ الميزة بالتأكيد.قم بحساب الفرق المحدد بين التعليمات البرمجية التي يتم ممارستها مع الميزة و...-بدون تحديد التعليمات البرمجية التي تركز بشكل أكبر على دعم الميزة.

يمكنك بطبيعة الحال الحصول على حدود أكثر صرامة عن طريق تشغيل المزيد من ميزات التمارين والمزيد من ميزات عدم التمرين وحساب الاختلافات عبر اتحادات تلك المجموعات.

توجد أدوات TC لـ C++، على سبيل المثال، "gcov".أعتقد أن معظمهم لن يسمحوا لك/يساعدوك في حساب مثل هذه الاختلافات المحددة في النتائج؛يبدو أن العديد من أدوات TC ليس لديها أي دعم لمعالجة المجموعات المغطاة.(تُنشئ شركتي مجموعة من أدوات TC التي تتمتع بهذه الإمكانية، بما في ذلك حساب اختلافات مجموعة التغطية، بما في ذلك C++).

إذا كنت تريد فعلا أن يستخرج الكود ذي الصلة، فإن أدوات TC لا تفعل ذلك.إنهم يخبرونك فقط بالرمز عن طريق تحديد مناطق النص في الملفات المصدر.معظم أدوات تغطية الاختبار تغطي التقرير فقط خطوط مثل مناطق النص؛ويرجع ذلك جزئيًا إلى أن الآلات التي تستخدمها العديد من أدوات تغطية الاختبار تقتصر على أرقام الأسطر المسجلة بواسطة المترجم.

ومع ذلك، يمكن للمرء أن يكون لديه أدوات تغطية اختبارية دقيقة في الإبلاغ عن مناطق النص من حيث بدء الملف/السطر/العمود حتى إنهاء الملف/السطر/العمود (مهم، أدوات شركتي تفعل ذلك).باستخدام هذه المعلومات، من السهل جدًا إنشاء برنامج بسيط لقراءة الملفات المصدر واستخراج التعليمات البرمجية التي تم تنفيذها حرفيًا.(وهذا لا يعني أن الكود المستخرج هو برنامج جيد الصياغة!على سبيل المثال، لن يتم تضمين إعلانات البيانات في الأجزاء المنفذة على الرغم من أنها ضرورية).

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