LibreOffice - офис LibreOffice:определите часть исходного кода, ответственную за печать

Question

Я пытаюсь реализовать некоторые дополнительные функциональные возможности в процессе печати LibreOffice (некоторая специальная информация должна автоматически добавляться на поля каждой печатаемой страницы).Я использую RHEL 6.4 с LibreOffice 4.0.4 и Gnome 2.28.

Моя цель - исследовать поток данных между LibreOffice и системными компонентами и определить, какие исходные коды отвечают за печать.После этого мне придется изменить эти части кода.

Теперь мне нужен совет по методам исследования исходного кода.Я нашел множество инструментов, и, с моей точки зрения,:

1. strace кажутся очень низкоуровневыми;
2. gprof требуется, чтобы двоичные файлы были перекомпилированы с CFLAGS "-pg";понятия не имею, как это сделать с помощью LibreOffice;
3. systemtap можно прощупывать только системные вызовы, не так ли?
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 (я определил его с помощью strace и ps aux).Я нажал CTRL+P и кнопка "ОК".Затем я закрыл приложение, надеясь увидеть функцию, отвечающую за инициализацию процесса печати в журналах.

Тот Самый callgrind выходные данные были обработаны с помощью Gprof2Dot инструмент в соответствии с этим ответом.К сожалению, я не вижу на картинке ни интересующих меня действий, ни графика вызовов как есть.

Я буду признателен за любую информацию о правильном способе решения такой проблемы.Спасибо.

Answer 1

Правильный способ решения этой проблемы - помнить, что LibreOffice имеет открытый исходный код.Весь исходный код задокументирован, и вы можете ознакомиться с документацией по адресу docs.libreoffice.org.Не делайте этого трудным путем :)

Кроме того, помните, что диалоговое окно настройки принтера не зависит от LibreOffice, скорее, оно предоставляется операционной системой.

Answer 2

То, что вам нужно, - это инструмент для идентификации интересующего исходного кода.Инструменты тестового покрытия (TC) могут предоставить эту информацию.

Что делают инструменты TC, так это определяют, какие фрагменты кода выполнялись при выполнении программы;думайте об этом как о сборе как о наборе областей кода.Обычно инструменты TC используются в сочетании с тестами (интерактивными / модульными / интеграционными / системными), чтобы определить, насколько эффективны тесты.Если был выполнен только небольшой объем кода (как обнаружено инструментом TC), тесты интерпретируются как неэффективные или неполные;если был покрыт большой процент, у вас есть хорошие тесты и разумное обоснование для отправки продукта (при условии, что все тесты пройдены).

Но вы можете использовать инструменты TC, чтобы найти код, реализующий функции.Сначала вы выполняете какой-либо тест (или, возможно, вручную запускаете программное обеспечение), чтобы использовать интересующую функцию, и собираете данные TC.Это сообщает вам набор всего использованного кода, если эта функция используется;это переоценка интересующего вас кода.Затем вы запускаете программу, прося ее выполнить какое-то аналогичное действие, но которое не использует эту функцию.Это идентифицирует набор кода, который определенно не реализует данную функцию.Вычислите заданную разницу кода, выполняемого с функцией, и ...-без, чтобы определить код, который в большей степени ориентирован на поддержку функции.

Естественно, вы можете получить более жесткие границы, выполняя больше упражнений-функций и больше не-упражнений-функций и вычисляя различия по объединениям этих наборов.

Существуют инструменты TC для C ++, например, "gcov".Большинство из них, я думаю, не позволят / помогут вам вычислить такие заданные различия по результатам;многие инструменты TC, похоже, не имеют никакой поддержки для манипулирования закрытыми наборами.(Моя компания создает семейство инструментов TC, которые обладают такой возможностью, включая вычисление различий в наборе данных, включая C ++).

Если ты действительно этого хочешь извлечь соответствующий код, инструменты TC этого не делают.Они просто сообщают вам, какой код используется, обозначая текстовые области в исходных файлах.Большинство инструментов тестирования охватывают только отчет линии как таковые текстовые области;отчасти это связано с тем, что механизм, используемый многими инструментами тестового покрытия, ограничен номерами строк, записанными компилятором.

Однако у вас могут быть инструменты тестового покрытия, которые точно отображают текстовые области с точки зрения начального файла / строки / столбца до конечного файла / строки / столбца (гм, инструменты моей компании, оказывается, делают это).Располагая этой информацией, довольно просто создать простую программу для чтения исходных файлов и извлечения буквально выполненного кода.(Это не означает, что извлеченный код является хорошо сформированной программой!например, объявления данных не будут включены в выполняемые фрагменты, хотя они необходимы).

OP не говорит, что он намерен делать с таким кодом, поэтому набор фрагментов может быть всем, что нужно.Если он хочет извлечь код и необходимые объявления, ему понадобятся более сложные инструменты, которые могут определить необходимые объявления.Инструменты преобразования программ с полными анализаторами и распознавателями имен для исходного кода могут предоставить необходимые для этого возможности.Это значительно сложнее в использовании, чем просто инструменты тестирования покрытия с выделением текста ad hoc extraction.