前提条件

使用可能なコード形式

C 言語および C++ 言語を使用する場合は、以下の 3 つのコード形式を使用できます。

GCC でのコード形式の処理

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

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

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

関連情報

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

前提条件

手順

関連情報

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

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

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

$ 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 で提供される、GCC コンパイラーおよびリンカーのバージョンが複数含まれます。これらのバージョン間の C++ ABI の互換性は以下のとおりです。

関連資料

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

前提条件

手順

関連情報

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

前提条件

手順

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

関連情報

開発者は、完全にコンパイルされた言語でアプリケーションを構築する際に、静的リンクまたは動的リンクを使用できます。本セクションでは、Red Hat Enterprise Linux で C 言語および C++ 言語した場合の違い (特にコンテキストについて) を説明します。Red Hat は、Red Hat Enterprise Linux のアプリケーションで静的リンクを使用することは推奨していません。

静的リンクおよび動的リンクの比較

静的リンクは、作成される実行可能ファイルのライブラリーの一部になります。動的リンクは、これらのライブラリーを別々のファイルとして保持します。

動的リンクおよび静的リンクは、いくつかの点で異なります。

上述の不利な点により、静的リンクは、特にアプリケーション全体、glibc ライブラリー、および libstdc++ ライブラリーに対しては、使用しないようにする必要があります。

静的リンクを使用する理由

以下のようなケースでは、静的リンクは妥当なオプションとして選択できます。

関連情報

ライブラリーは、プログラムで再利用可能なコードのパッケージです。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 つの手順でコンパイルし、リンクする方法

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

関連資料

静的なライブラリーは、オブジェクトファイルを含むアーカイブとして利用できます。リンク後、それらは作成された実行可能ファイルの一部となります。

前提条件

手順

ソースとオブジェクトファイルからプログラムをリンクするには、静的にリンクされたライブラリー 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 オプションとは異なります。-Wl オプションの後に、リンカーのオプションをコンマ区切りのリストにして入力します。ただし、他の gcc オプションには、スペース区切りのリストにしてオプションを指定する必要があります。gcc が使用する ld リンカーには、-Bstatic と -Bdynamic のオプションがあり、このオプションの後に来るライブラリーを静的または動的にリンクすべきかどうかを指定します。-Bstatic とライブラリーをリンカーに渡した後、後続のライブラリーを -Bdynamic オプションで動的にリンクするには、デフォルトの動的リンクの動作を手動で復元する必要があります。

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

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

関連資料

ライブラリーには、特別なファイル名規則が使用されます。foo として知られるライブラリーは、ファイル lib foo.so または lib foo.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 はビルドプロセスの命令が含まれる Makefile を読み込みます。Makefile には、特定のアクション (レシピ) で特定の条件 (ターゲット) を満たす方法を記述する複数の ルール が含まれています。ルールは、別のルールに階層的に依存できます。

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

Makefile の詳細

Makefile は比較的単純な構文を使用して 変数 と ルール を定義します。Makefile は ターゲット と レシピ で設定されます。ターゲットでは、ルールが実行された場合の出力を指定します。レシピの行は、TAB 文字で開始する必要があります。

通常 Makefile には、ソースファイルをコンパイルするルール、作成されるオブジェクトファイルをリンクするルール、および階層の上部にあるエントリーポイントとして機能するターゲットが含まれます。

1 つのファイル (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 が必要です。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

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

$ ltrace ... |& tee your_log_file.log

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

前提条件

詳細

コアダンプは、アプリケーションの動作が停止した時点のアプリケーションのメモリーの一部のコピーで、ELF 形式で保存されます。コアダンプには、アプリケーションの内部変数、スタックすべてが含まれ、アプリケーションの最終的な状態を検査することができます。それぞれの実行可能ファイルおよびデバッグ情報を追加すると、実行中のプログラムを分析するのと同様に、デバッガーでコアダンプファイルを分析できます。

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

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

手順

関連情報

前提条件

手順

関連資料

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

前提条件

手順

gcore を使用してプロセスメモリーをダンプするには、以下を実行します。

関連情報

プロセスのメモリーをダンプしないようにマークできます。これにより、リソースを節約し、プロセスのメモリーに機密データが含まれている場合にセキュリティーを強化することができます。カーネルのコアダンプ (kdump) および手動のコアダンプ (gcore、GDB) は、このようにマークされたメモリーをダンプしません。

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

前提条件

手順

関連資料

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

特定のツールが選択されていない場合における、デフォルトのツールとしての memcheck 関数。

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

$ valgrind --tool=toolname program

toolname の引数の一覧については、「Valgrind ツール」 を参照してください。Valgrind ツールのスイート以外に、 none は toolname の有効な引数として使用できます。この引数を使用すると、プロファイルを実行せずにプログラムを 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 の使用 の章をを参照してください。

$ ocount -e INST_RETIRED -- sleep 1

Events were actively counted for 1.0 seconds.
Event counts (actual) for /bin/sleep:
Event Count % time counted
INST_RETIRED 683,011 100.00

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

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

役に立つ perf コマンドには、以下が含まれます。

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

プログラムの実行の統計またはサンプルを収集するために基本的な 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) ]

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