前提条件/事前作業

考えられるコード形式

C および C++ 言語を使用する場合は、コード形式が 3 つあります。

GCC でのコード形式の処理

ソースコードから実行可能なコードを生成するには、2 つの手順を実行してください。各手順では、異なるアプリケーションまたはツールが必要です。GCC は、コンパイラーおよびリンカーどちらにも、インテリジェントドライバーとして使用可能です。これにより、必要なアクションに gcc のコマンド 1 つだけで対応できます。GCC は自動的に必要なアクション (コンパイルおよびリンク) とそのシーケンスを選択します。

ステップ 1 だけ、ステップ 2 だけ、ステップ 1 と 2 両方というように、GCC を実行することができます。これは、入力タイプや要求する出力タイプにより決定されます。

大規模なプロジェクトには、アクション毎に個別に GCC を実行するビルドシステムが必要なため、GCC が両方同時に実行できる場合でも 2 つの異なるアクションとしてコンパイルとリンクを実行するように検討するほうが良いでしょう。

その他のリソース

実行可能ファイルから直接作成するのではなく、ソースファイルからオブジェクトコードファイルを作成するには、 GCC にオブジェクトコードファイルのみを出力として作成するように指示する必要があります。このアクションは、大規模なプロジェクトのビルドプロセスの基本操作となります。

前提条件/事前作業

手順

その他のリソース

デバッグの情報が大きい場合には、デフォルトでは実行可能ファイルは含まれません。GCC を使用した C および C++ アプリケーションのデバッグを有効化するには、コンパイラーに対して、ファイルを作成するように、明示的に指示する必要があります。

GCC を使用したデバッグ情報の作成の有効化

コードのコンパイルおよびリンク時には GCC でデバッグ情報の作成を有効化するには、-g オプションを使用します。

$ gcc ... -g ...

その他のリソース

1 つのプログラムは、複数の機械語命令シーケンスに変換可能です。コンパイル時にコード分析用のリソースがより多く割り当てられると、より最適な結果が得られます。

GCC でのコードの最適化

GCC では、-Olevel オプションを使用して最適化レベルを設定できます。このオプションでは、level の部分に各種値を指定することができます。

リリースビルドの場合の最適化オプションは、-O2 を推奨します。

開発中は、場合によってはプログラムやライブラリーのデバッグを行えるように -Og オプションのほうが便利です。バグによっては、特定の最適化レベルでのみ出現するので、リリースの最適化レベルでプログラムまたはライブラリーをテストするようにしてください。

GCC では、個別の最適化を有効にするオプションが多数含まれています。詳細情報は、以下の追加リソースを参照してください。

その他のリソース

コンパイラーで、ソースコードをオブジェクトコードに変換する場合には、さまざまなチェックを追加して、一般的に悪用される状況などを回避し、セキュリティーを強化することができます。適切なコンパイラーオプションセットを選択して、ソースコードを変更せずに、よりセキュアなプログラムやライブラリーを制作することができます。

リリースバージョンのオプション

Red Hat Enterprise Linux を使用する開発者には、以下のオプション一覧が最小限必要なオプションとなります。

$ gcc ... -O2 -g -Wall -Wl,-z,now,-z,relro -fstack-protector-strong -D_FORTIFY_SOURCE=2 ...

開発オプション

開発時にセキュリティーの欠陥を検出する場合には、以下のオプションを推奨します。これらのオプションは、リリースバージョンのオプションと合わせて使用してください。

$ gcc ... -Walloc-zero -Walloca-larger-than -Wextra -Wformat-security -Wvla-larger-than ...

その他のリソース

C または C++ アプリケーション構築の最後の手順は、リンクです。リンクをすることで、オブジェクトファイルやライブラリーをすべて実行可能なファイルに統合します。

前提条件/事前作業

手順

その他のリソース

Red Hat エコシステムには、Red Hat Enterprise Linux および Red Hat Developer Toolset の複数のバージョンが含まれます。これらのバージョン間の C++ ABI の互換性は以下のとおりです。

その他のリソース

以下の例では、最小限の C プログラムのサンプルを構築する手順を説明します。

前提条件/事前作業

手順

その他のリソース

以下の例では、最小限の C++ プログラムのサンプルを構築する手順を説明します。

前提条件/事前作業

手順

特別なファイルの命名規則をライブラリーに使用します。foo として知られるライブラリーは、libfoo.so または libfoo.a ファイルとして存在する必要があります。この規則は、リンクする GCC の入力オプションで、自動的に理解されますが、出力オプションでは理解されません。

その他のリソース

ライブラリーは、プログラムで再利用可能なコードのパッケージです。C または C++ ライブラリーは、以下の 2 つの部分で構成されます。

ライブラリーを使用するコードのコンパイル

ヘッダーファイルでは、ライブラリーで提供する関数や変数など、ライブラリーのインターフェースを記述します。コードをコンパイルする場合に、ヘッダーファイルからの情報が必要です。

通常、ライブラリーのヘッダーファイルは、アプリケーションのコードとは別のディレクトリーに配置されます。ヘッダーファイルの場所を GCC に指示するには、-I オプションを使用します。

$ gcc ... -Iinclude_path ...

include_path は、ヘッダーファイルのディレクトリーへの実際のパスに置き換えます。

-I オプションは、複数回使用して、ヘッダーファイルを含むディレクトリーを複数追加することができます。ヘッダーファイルを検索する場合は、-I オプションで表示順に、これらのディレクトリーが検索されます。

ライブラリーを使用するコードのリンク

実行可能なファイルをリンクする場合には、アプリケーションのオブジェクトコードおよび、ライブラリーのバイナリーコードの両方が利用できる状態でなければなりません。静的および動的ライブラリーのコードは、形式が異なります。

アーカイブファイルまたは共有オブジェクトファイルの場所を GCC に渡すには、-L オプションを使用します。

$ gcc ... -Llibrary_path -lfoo ...

library_path はライブラリーのディレクトリーへの実際のパスに置き換えます。

-I オプションは、複数回使用して、ディレクトリーを複数追加することができます。ライブラリーを検索する場合は、-L オプションで表示順に、これらのディレクトリーが検索されます。

オプションの指定順は重要です。対象のライブラリーがディレクトリーにリンクされていることが分からないと、GCC は、ライブラリー foo をリンクできません。そのため、-L オプションを使用して先にライブラリーディレクトリーを指定してから、-l オプションでライブラリーをリンクするようにしてください。

1 つの手順でライブラリーを使用するコードをコンパイルとリンクする方法

gcc コマンド 1 つでコードをコンパイルリンクできる場合には、上記のオプションを一度に使用します。

その他のリソース

静的ライブラリーは、オブジェクトファイルを含むアーカイブファイルとして提供します。リンク後には、作成される実行可能ファイルで必要不可欠な部分になります。

前提条件/事前作業

手順

ソースとオブジェクトファイルからのプログラムをリンクするには、静的にリンクされたライブラリー foo (libfoo.a として検索可能) を追加します。

動的ライブラリーは、スタンドアロンの実行可能ファイルとして提供します。このファイルは、リンク時、ランタイム時に必要です。これらのファイルは、アプリケーションの実行ファイルからは独立しています。

前提条件/事前作業

プログラムの動的ライブラリーへのリンク

動的ライブラリー foo にプログラムをリンクする手順:

$ gcc ... -Llibrary_path -lfoo ...

プログラムを動的ライブラリーにリンクすると、作成されるプログラムは常にランタイム時にライブラリーを読み込む必要があります。ライブラリーの場所を特定するオプションは 2 つあります。

実行可能ファイルに保存された rpath の値を使用する方法

rpath は、リンク時に実行可能ファイルの一部として保存される特別な値です。その後、実行可能ファイルからプログラムを読み込む時に、ランタイムリンカーが rpath の値を使用してライブラリーファイルの場所を特定します。

GCC とリンクし、library_path のパスを rpath として保存します。

$ gcc ... -Llibrary_path -lfoo -Wl,-rpath=library_path ...

library_path のパスは、libfoo.so ファイルを含むディレクトリーを参照する必要があります。

あとでプログラムを実行するには、以下を実行します。

$ ./program

LD_LIBRARY_PATH 環境変数を使用する方法

プログラムの実行可能ファイルに rpath がない場合は、ランタイムリンカーは LD_LIBRARY_PATH の環境変数を使用します。この変数の値は、共有オブジェクトがあるパスに合わせて、プログラム毎に変更する必要があります。

rpath セットがなく、ライブラリーが library_path パスにある状態で、プログラムを実行します。

$ export LD_LIBRARY_PATH=library_path:$LD_LIBRARY_PATH
$ ./program

rpath の値を空白にすると柔軟性が出てきますが、プログラムを実行するたびに、LD_LIBRARY_PATH の変数を設定する必要があります。

ライブラリーのデフォルトのディレクトリーへの配置

ランタイムのリンカー設定では、複数のディレクトリーを動的ライブラリーファイルのデフォルトの場所として指定します。このデフォルトの動作を使用するには、ライブラリーを適切なディレクトリーにコピーしてください。

動的リンカーの動作に関する全説明は、本書の対象外です。詳しい情報は、以下のリソースを参照してください。

場合によっては、静的ライブラリーと動的ライブラリーの両方をリンクする必要があります。このような場合には、課題が浮上します。

前提条件/事前作業

概要

gcc は、動的、静的ライブラリーの両方を認識します。-lfoo オプションが指定されている場合には、gcc は、動的にリンクされた foo ライブラリーを含む共有オブジェクト (.so ファイル) の場所をまず特定し、静的ライブラリーを含むアーカイブファイル (.a) を検索します。そのため、今回の検索の結果、以下の状態になります。

このようなルールがあるので、リンクするために、静的または動的ライブラリーを選択する場合は gcc が検索可能なバージョンのみを指定するようにします。これは、-Lpath オプションで指定する場合に、静的/動的ライブラリーを含むディレクトリーを追加するか、追加しないかである程度制御することができます。

また、動的リンクがデフォルトの設定であるため、明示的にリンクを指定する必要があるのは、静的/動的の両バージョンのライブラリーを静的にリンクする必要がある場合のみです。考えられる方法は以下の 2 つです。

ファイルで静的ライブラリーを指定する方法

通常、gcc は、-lfoo オプションを指定して、foo ライブラリーにリンクするように設定しますが、代わりに、ライブラリーを含む libfoo.a への完全パスを指定することも可能です。

$ gcc ... path/to/libfoo.a ...

ファイルの拡張子 .a から、gcc は、このファイルはプログラムとリンクするためのライブラリーであることを理解します。ただし、ライブラリーパスへの完全なパスを指定するのは柔軟な方法ではありません。

-Wl オプションの使用

gcc オプションの -Wl は、基盤のリンカーにオプションを渡すための特別なオプションです。このオプションの構文は、他の gcc オプションとは異なります。このオプションの後に、リンカーのオプションのコンマ区切りのリストを指定して、スペースで区切る gcc オプションと混同されないようにします。

gcc が使用する ld リンカーには、-Bstatic と -Bdynamic のオプションがあり、このオプションの後に来るライブラリーが静的、または動的にリンクすべきかどうかを指定します。-Bstatic とライブラリーをリカーに渡した後、以降のライブラリーを -Bdynamic オプションで動的にリンクするには、デフォルトの動的リンクの動きを手動で復元する必要があります。

プログラムをリンクするには、まず 静的に (libfirst.a) ライブラリーをリンクして、ルギに 動的に (libsecond.so) リンクします。

$ gcc ... -Wl,-Bstatic -lfirst -Wl,-Bdynamic -lsecond ...

その他のリソース

特別なファイルの命名規則をライブラリーに使用します。foo として知られるライブラリーは、libfoo.so または libfoo.a ファイルとして存在する必要があります。この規則は、リンクする GCC の入力オプションで、自動的に理解されますが、出力オプションでは理解されません。

その他のリソース

動的に読み込んだライブラリー (共有オブジェクト) は、soname と呼ばれるメカニズムを使用して、複数の互換性のあるライブラリーを管理します。

前提条件/事前作業

問題の概要

動的に読み込んだライブラリー (共有オブジェクト) は、独立した実行可能ファイルとして存在します。そのため、依存するアプリケーションを更新せずに。ライブラリーを更新することができます。ただし、このコンセプトでは、以下の問題が発生します。

soname のメカニズム

この問題を解決するには、Linux では soname と呼ばれるメカニズムを使用します。

ライブラリー foo の X.Y バージョンは、バージョン番号 (X) が同じ値でマイナーバージョンが異なるバージョンと、ABI の互換性があります。互換性を確保してマイナーな変更を加えると、Y の数字が増加します。互換性がなくなるような、メジャーな変更を加えると、X の数字を増やします。

実際の foo ライブラリーバージョン X.Y は、libfoo.so.x.y ファイルとして存在します。ライブラリーファイルの中に、soname が libfoo.so.x の値として記録され、互換性を指定します。

アプリケーションを構築すると、リンカーは libfoo.so ファイルを検索して、ライブラリーを特定します。この名前のシンボリックリンクが存在し、実際のライブラリーファイルを参照する必要があります。次にリンカーは、ライブラリーファイルから soname を読み込み、アプリケーションの実行可能ファイルに記録します。最後に、リンカーにより、ファイル名でなく、soname を使用してライブラリー上で依存関係を宣言するように、アプリケーションが作成されます。

ランタイムの動的リンカーが実行前にアプリケーションをリンクすると、soname がアプリケーションの実行可能ファイルから読み込まれます。この soname は libfoo.so.x と呼ばれ、この名前のシンボリックリンクが存在し、実際のライブラリーファイルを参照する必要があります。これにより、soname が変更されないので、バージョンの Y の部分の有無にかかわらず、ライブラリーを読み込むことができるようになります。

ファイルからの soname の読み込み

somelibrary ライブラリーファイルの soname を表示します。

$ objdump -p somelibrary | grep SONAME

somelibrary は、検証するライブラリーの実際のファイル名に置き換えます。

ライブラリーを動的にリンクすると (共有オブジェクト)、コードを再利用して、リソースを確保し、ライブラリーコードの更新が簡単になり、セキュリティーの強化を図ることができます。このセクションでは、ソースから動的ライブラリーを構築してインストールする手順を説明します。

前提条件/事前作業

手順

その他のリソース

オブジェクトファイルを特別なアーカイブファイルに変換して、静的にリンクするためにライブラリーを作成することが可能です。

前提条件/事前作業

手順

その他のリソース

特定のプロジェクトのソースファイルから使用可能な形式 (通常は実行可能ファイル) を作成するには、必要な手順を完了します。後で反復できるように、アクションとそのシーケンスを記録します。

Red Hat Enterprise Linux には、この目的用に設計されたビルドシステム、GNU make が含まれています。

前提条件/事前作業

GNU make

GNU make はビルドプロセスの命令が含まれる Makefiles を読み込みます。Makefile には、特定のアクション (recipe) で特定の条件 (target) を満たす方法を記述する複数の rules が含まれています。ルールは、別のルールに階層的に依存することができます。

オプションを指定せずに make を実行すると、現在のディレクトリーで Makefile を検索し、デフォルトのターゲットに到達しようと試みます。実際の Makefile ファイル名は Makefile、makefile および GNUmakefile です。デフォルトのターゲットは、Makefile の内容で決まります。

Makefile の詳細

Makefiles は比較的単純な構文を使用して variables と rules を定義します。Makefiles は targetと recipe で構成されます。ターゲットでは、ルールが実行された場合にどのような出力が表示されるのかを指定します。レシピの行は、TAB 文字で開始する必要があります。

通常、Makefile は、ソースファイルをコンパイルするためのルール、作成されるオブジェクトファイルをリンクするためにのルール、階層上部のエントリーポイントとしての役割を果たすターゲットで構成されます。

単一のファイル (hello.c) で構成される C プログラムを構築するには、以下の Makefile を検討してください。

all: hello

hello: hello.o
        gcc hello.o -o hello

hello.o: hello.c
        gcc -c hello.c -o hello.o

上記の例では、ターゲット all に到達するには、ファイル hello iが必要です。hello を取得するには、hello.o (gcc でリンク) が必要で、hello.c (gcc でコンパイル) をもとに作成します。

ターゲットの all は、ピリオド (.) で開始されない最初のターゲットであるため、デフォルトのターゲットとなっています。この Makefile が現在のディレクトリーに含まれている場合には、引数なしに make を実行するのは、make all するのと同じ作業です。

一般的な Makefile

より一般的な Makefile は、この手順を正規化する変数を使用し、ターゲット「clean」を追加して、ソースファイル以外のすべてを削除します。

CC=gcc
CFLAGS=-c -Wall
SOURCE=hello.c
OBJ=$(SOURCE:.c=.o)
EXE=hello

all: $(SOURCE) $(EXE)

$(EXE): $(OBJ)
        $(CC) $(OBJ) -o $@

%.o: %.c
        $(CC) $(CFLAGS) $< -o $@

clean:
        rm -rf $(OBJ) $(EXE)

このような Makefile にソースファイルをさらに追加するには、SOURCE 変数が定義されている行に追加するだけです。

その他のリソース

以下の例の手順に従い、Makefile を使用して C プログラムを構築します。

前提条件/事前作業

手順

その他のリソース

make の詳細情報は、以下に記載のリソースを参照してください。

インストールされているドキュメント

オンラインのドキュメント

アプリケーションやライブラリーをデバッグするには、デバッグ情報が必要です。以下のセクションでは、この情報を取得する方法を説明します。

$ gcc ... -g ...

アプリケーションが正しく機能しない理由を特定するには、実行を管理して、デバッガーの内部状況を検証します。このセクションでは、このタスクにおける GNU デバッガー (GDB) の使用方法を説明します。

$ gdb program

(gdb) file path/to/program

アプリケーションの実行可能コードは、オペレーティングシステムや共有ライブラリーのコードと対話します。これらの対話に関するアクティビティーログを記録すると、実際のアプリケーションコードをデバッグせずに、アプリケーションの動作を詳細にわたり知ることができます。また、アプリケーションの対話を分析すると、バグが発生した状況をピンポイントで特定しやすくなります。

$ strace ... | tee your_log_file.log

$ ltrace ... | tee your_log_file.log

以下のセクションでは、コアダンプ の概要、その用途について説明します。

前提条件/事前作業

説明

コアダンプは、アプリケーション機能が停止した時点のアプリケーションメモリーの一部を ELF 形式で保存したコピーのことです。コアダンプには、アプリケーションの内部変数、スタックすべてが含まれ、アプリケーションの最終的な状態を検査することができます。適切な実行ファイルやデバッグ情報が指定されている場合には、実行中のプログラムを分析するのに似た方法で、デバッガーを使用してコアダンプファイルを分析することができます。

Linux オペレーティングシステムのカーネルは、コアダンプの自動記録が有効化去れている場合には、コアダンプを自動的に記録できます。また、実行中のアプリケーションにシグナルを送り、実際の状態に関係なくコアダンプを生成することも可能です。

アプリケーションのクラッシュを記録するには、コアダンプの保存内容を設定し、システムに関する情報を追加します。

手順

その他のリソース

前提条件/事前作業

手順

その他のリソース

コアダンプのデバッグに関するワークフローでは、プログラムの状態をオフラインで分析できます。対象のプロセスで環境にアクセスするのが困難な場合など、実行中のプログラムでこのワークフローを使用すると有益な場合があります。gcore コマンドを使用して、実行中にプロセスのメモリーをダンプすることができます。

前提条件/事前作業

手順

gcore を使用してプロセスメモリーをダンプします。

その他のリソース

プロセスのメモリーをダンプしないように、マークすることができます。カーネルコアダンプ (kdump) や手動のコアダンプ (gcore、GDB) は、このようにマークされたメモリーをダンプしません。

このように保護されていても、プロセスメモリーの全コンテンツをダンプする必要がある場合があります。以下の手順では、GDB デバッガーを使用して、全コンテンツをダンプする方法を説明します。

前提条件/事前作業

手順

その他のリソース

Valgrind スイートは、以下のツールで構成されています。

Valgrind は、独自のプロファイリングツールを開発することができます。これと合わせて、Valgrind には lackey ツールが含まれており、独自のツールを作成するためのテンプレートとして使用可能なサンプルとして使用できます。

valgrind パッケージとその依存関係は、Valgrind プロファイルの実行に必要なツールをすべてインストールします。Valgrind でプログラムをプロファイリングするには、以下を使用します。

~]$ valgrind --tool=toolname program

toolname の引数の一覧については、「Valgrind ツール」を参照してください。Valgrind ツールスイート以外に、toolname では none も有効な引数として使用できます。この引数では、プロファイリングせずに Valgrind でプログラムを実行できます。Valgrind 自体のデバッグやベンチマーク化をする時に、これは便利です。

Valgrind に、固有のファイルに情報すべてを送信するように指示することも可能です。これには、--log-file=filename のオプションを使用します。実行可能ファイル hello のメモリー使用状況を確認して、output にプロファイル情報を送信するには、以下を使用します。

~]$ valgrind --tool=memcheck --log-file=output hello

Valgrind に関する詳しい情報は、「追加情報」や、ツールの Valgrind スイートに関する他のドキュメントを参照してください。

Valgrind の詳細情報は、man valgrind を参照してください。Red Hat Enterprise Linux には、包括的な Valgrind ドキュメント が PDF および HTML 形式で含まれています。これらのドキュメントは以下の場所にあります。

operf は、推奨されるプロファイリングデータ収集ツールです。このツールは、初期設定が必要なく、すべてのオプションはコマンドラインで渡されます。レガシーの opcontrol ツールとは異なり、operf は root 権限なしに実行できます。operf ツールの使用方法に関する詳しい情報は、『システム管理者ガイド』の「operf の使用」の章を参照してください。

OProfile に関する詳細情報は、oprofile(1) man ページを参照してください。Red Hat Enterprise Linux には、OProfile に関する包括的なガイドが含まれており、このガイドは file:///usr/share/doc/oprofile-version/ にあります。

SystemTap の詳細情報は、以下の Red Hat ドキュメントを参照してください。

Useful perf コマンドには以下が含まれます。

perf コマンドの完全一覧を取得するには、perf help を使用します。perf コマンドごとに、man ページの情報を取得するには、perf help command を使用します。

プログラム実行の統計やサンプルと収集するための基本的な PCL インフラストラクチャーは、比較的単純です。以下のセクションでは、全体的な統計やサンプルのシンプルな例を紹介します。

make およびその子についての統計情報を収集するには、以下のコマンドを使用します。

# perf stat -- make all

perf コマンドは、多くの異なるハードウェアおよびソフトウェアカウンターを収集し、以下の情報を表示します。

Performance counter stats for 'make all':

  244011.782059  task-clock-msecs         #      0.925 CPUs
          53328  context-switches         #      0.000 M/sec
            515  CPU-migrations           #      0.000 M/sec
        1843121  page-faults              #      0.008 M/sec
   789702529782  cycles                   #   3236.330 M/sec
  1050912611378  instructions             #      1.331 IPC
   275538938708  branches                 #   1129.203 M/sec
     2888756216  branch-misses            #      1.048 %
     4343060367  cache-references         #     17.799 M/sec
      428257037  cache-misses             #      1.755 M/sec

  263.779192511  seconds time elapsed

perf ツールはサンプルを記録することもできます。たとえば、make コマンドおよびその子に関するデータを記録するには、以下のコマンドを実行します。

# perf record -- make all

これで収集されたサンプル数とサンプルが保存されているファイルが表示されます。

[ perf record: Woken up 42 times to write data ]
[ perf record: Captured and wrote 9.753 MB perf.data (~426109 samples) ]

Red Hat Enterprise Linux 6.4 では、{} グループ構文に新機能が追加され、これによりコマンドライン上でイベントグループが指定されている方法に基づいてイベントグループが作成できるようになりました。

最新の --group や -g オプションには変更はありません。record、stat、top コマンドが指定されていれば、指定イベントすべてが単一グループのメンバーになり、最初のイベントがグループリーダーとなります。

新たな {} グループ構文は、以下のようなグループの作成を可能にします。

# perf record -e '{cycles, faults}' ls

上記のコマンドを実行すると、cycles と faults イベントを含む単一のイベントグループが作成され、cycles がグループリーダーになります。

すべてのグループはスレッドおよび CPU に関して作成されます。このため、CPU が 4 つあるサーバー上で 2 つのスレッド内のイベントは、8 つの異なるグループを作成することになります。

グループに標準イベント修飾子を使うことができます。これは、グループ内の全イベントにまたがるもので、各イベント修飾子設定を更新します。

# perf record -r '{faults:k,cache-references}:p'

上記のコマンドでは、:kp 修飾子が faults に使われ、:p 修飾子が cache-references イベントに使われることになります。

Error: open_counter returned with 16 (Device or resource busy). /usr/bin/dmesg may provide additional information.

Fatal: Not all events could be opened.

perf コマンドを使用するには、まず OProfile をシャットダウンします。

# opcontrol --deinit

その後に perf.data を分析してサンプルの相対頻度を測定することができます。レポート出力には、コマンド、オブジェクト、サンプルの機能などが含まれます。perf report を使って perf.data の分析を出力します。たとえば、以下のコマンドは最も時間がかかる実行可能ファイルのレポートを作成します。

# perf report --sort=comm

出力は以下のようになります。

# Samples: 1083783860000
#
# Overhead          Command
# ........  ...............
#
    48.19%         xsltproc
    44.48%        pdfxmltex
     6.01%             make
     0.95%             perl
     0.17%       kernel-doc
     0.05%          xmllint
     0.05%              cc1
     0.03%               cp
     0.01%            xmlto
     0.01%               sh
     0.01%          docproc
     0.01%               ld
     0.01%              gcc
     0.00%               rm
     0.00%              sed
     0.00%   git-diff-files
     0.00%             bash
     0.00%   git-diff-index

左のコラムはサンプルの相対頻度を示しています。この出力では、make が xsltproc および pdfxmltex で最も多くの時間を消費していることを示しています。make が完了する時間を短縮するには、xsltproc と pdfxmltex にフォーカスします。xsltproc が実行する機能を一覧表示するには、以下のコマンドを実行します。

# perf report -n --comm=xsltproc

以下が生成されます。

comm: xsltproc
# Samples: 472520675377
#
# Overhead  Samples                    Shared Object  Symbol
# ........ ..........  .............................  ......
#
    45.54%215179861044  libxml2.so.2.7.6               [.] xmlXPathCmpNodesExt
    11.63%54959620202  libxml2.so.2.7.6               [.] xmlXPathNodeSetAdd__internal_alias
     8.60%40634845107  libxml2.so.2.7.6               [.] xmlXPathCompOpEval
     4.63%21864091080  libxml2.so.2.7.6               [.] xmlXPathReleaseObject
     2.73%12919672281  libxml2.so.2.7.6               [.] xmlXPathNodeSetSort__internal_alias
     2.60%12271959697  libxml2.so.2.7.6               [.] valuePop
     2.41%11379910918  libxml2.so.2.7.6               [.] xmlXPathIsNaN__internal_alias
     2.19%10340901937  libxml2.so.2.7.6               [.] valuePush__internal_alias