リブレオフィス:印刷を担当するソースコード部分を決定する

Question

LibreOffice の印刷プロセスにいくつかの追加機能を実装しようとしています (印刷されるすべてのページの余白にいくつかの特別な情報が自動的に追加される必要があります)。RHEL 6.4 と LibreOffice 4.0.4 および Gnome 2.28 を使用しています。

私の目的は、LibreOffice とシステム コンポーネント間のデータ フローを調査し、どのソース コードが印刷を担当しているかを判断することです。その後、コードのこれらの部分を変更する必要があります。

ソースコード調査の方法についてアドバイスが必要です。たくさんのツールを見つけましたが、私の観点からは次のとおりです。

1. strace 非常に低レベルのようです。
2. gprof 「-pg」CFLAGS を使用してバイナリを再コンパイルする必要があります。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

4 つの出力ファイルを受け取りました。

-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）。押しました CTRL+P そして「OK」ボタンを押します。次に、ログにプロセスの初期化を出力する関数が表示されることを期待してアプリケーションを閉じました。

の callgrind 出力はで処理されました Gprof2Dot この回答によるとツール。残念ながら、興味のあるアクションもコールグラフもそのままでは画像で見ることができません。

このような問題を解決する適切な方法についての情報をいただければ幸いです。ありがとう。

Answer 1

この問題を解決するための適切な方法は、LibreOfficeがオープンソースであることを思い出しています。ソースコード全体が文書化されており、 docs.libreoffice.org でドキュメントを閲覧することができます。それをしないでください:)

その上、プリンタ設定ダイアログはlibreOffice固有ではなく、OSによって提供されていることを忘れないでください。

Answer 2

必要なのは、対象のソース コードを識別するツールです。テスト カバレッジ (TC) ツールは、この情報を提供できます。

TC ツールが行うことは、プログラムの実行時にどのコード フラグメントが実行されたかを判断することです。コード領域のセットとして収集すると考えてください。通常、TC ツールは (対話型/単体/統合/システム) テストと組み合わせて使用​​され、テストがどの程度効果的であるかを判断します。少量のコードしか実行されていない場合 (TC ツールによって検出された場合)、テストは効果がないか不完全であると解釈されます。大部分がカバーされている場合は、テストが良好であり、製品を出荷する正当な理由があることになります (すべてのテストに合格したと仮定します)。

ただし、TC ツールを使用すると、機能を実装するコードを見つけることができます。まず、何らかのテストを実行して (またはソフトウェアを手動で実行して) 目的の機能を実行し、TC データを収集します。これにより、機能が使用されている場合に実行されたすべてのコードのセットがわかります。それは、関心のあるコードを過大評価していることになります。次に、プログラムを実行して、同様のアクティビティを実行するように要求しますが、その機能は実行されません。これにより、その機能が明らかに実装されていないコードのセットが特定されます。code-exercized-with-feature と ...-without のセットの差を計算して、機能のサポートに重点を置いたコードを決定します。

より多くの演習機能とより多くの非演習機能を実行し、それらのセットの和集合に対する差分を計算することで、自然により厳しい境界を得ることができます。

C++ には「gcov」などの TC ツールがあります。それらのほとんどは、結果に対するそのようなセットの違いを計算させたり、助けたりしないと思います。多くの TC ツールは、カバーされたセットの操作をサポートしていないようです。(私の会社は、C++ を含むカバレッジ セットの差分を計算するなど、この機能を備えた TC ツール ファミリを作成しています)。

実際にそうしたい場合は 抽出する 関連するコードを削除しても、TC ツールはそれを行いません。ソース ファイル内のテキスト領域を指定することで、どのようなコードであるかを示すだけです。ほとんどのテスト カバレッジ ツールはカバーされたレポートのみを提供します 行 そのようなテキスト領域。これは、多くのテスト カバレッジ ツールが使用する機構が、コンパイラーによって記録される行番号に限定されていることが部分的に原因です。

ただし、開始ファイル/行/列から終了ファイル/行/列までのテキスト領域を正確にレポートするテスト カバレッジ ツールを使用することはできます (まあ、私の会社のツールはたまたまこれを実行します)。この情報があれば、ソース ファイルを読み取り、実行されたコードを文字通り抽出する単純なプログラムを構築するのは非常に簡単です。(これは、抽出されたコードが整形式のプログラムであることを意味するものではありません。たとえば、データ宣言は必要ですが、実行されるフラグメントには含まれません)。

OP はそのようなコードで何をするつもりなのかを述べていないため、必要なのはフラグメントのセットだけである可能性があります。コードと必要な宣言を抽出したい場合は、必要な宣言を判断できるより高度なツールが必要になります。ソース コード用の完全なパーサーと名前リゾルバーを備えたプログラム変換ツールは、これに必要な機能を提供できます。これは、アドホック抽出テキスト抽出を使用した単なるテスト カバレッジ ツールよりも使用がかなり複雑です。