valgrind.bin - クラウドでオンライン

プログラム：

NAME

valgrind-プログラムのデバッグとプロファイリングのためのツールスイート

SYNOPSIS

バルグラインド [valgrind-オプション] [あなたのプログラム] [あなたのプログラムのオプション]

DESCRIPTION

ヴァルグリンド Linux実行可能ファイルをデバッグおよびプロファイリングするための柔軟なプログラムです。 それはで構成されています
ソフトウェアで合成CPUを提供するコア、および一連のデバッグと
プロファイリングツール。 アーキテクチャはモジュール式であるため、新しいツールを簡単に作成でき、
既存の構造を乱すことなく。

以下で説明するオプションの一部は、すべてのValgrindツールで機能し、一部はでのみ機能します
いくつかまたはXNUMXつ。 MEMCHECK OPTIONSセクションとその下のセクションでは、ツール固有について説明しています。
オプション。

このマニュアルページでは、基本的な使用法とオプションについてのみ説明します。 より包括的な情報については、
システムのHTMLドキュメントを参照してください。
$ INSTALL / share / doc / valgrind / html / index.html、またはオンライン：
http://www.valgrind.org/docs/manual/index.html.

TOOL SELECTION OPTIONS

単一の最も重要なオプション。

--tool = [ディフォルト： メモリチェック]
と呼ばれるValgrindツールを実行します ツール名例：memcheck、cachegrind、callgrind、helgrind、
drd、massif、lackey、none、exp-sgcheck、exp-bbv、exp-dhatなど。

BASIC OPTIONS

これらのオプションはすべてのツールで機能します。

-h - 助けて
コアと選択したツールの両方について、すべてのオプションのヘルプを表示します。 オプションの場合
繰り返されるそれは与えることと同等です --ヘルプ-デバッグ.

--ヘルプ-デバッグ
と同じ - 助けて、ただし、通常は次の目的でのみ使用されるデバッグオプションも一覧表示されます。
Valgrindの開発者。

- バージョン
Valgrindコアのバージョン番号を表示します。 ツールは独自のバージョンを持つことができます
数字。 ツールがコアの場合にのみ実行されるようにするためのスキームがあります
バージョンは、動作することが知られているバージョンです。 これは、の可能性を最小限に抑えるために行われました
ツールとコアのバージョンの非互換性から生じる奇妙な問題。

-q, - 静かな
サイレントに実行し、エラーメッセージのみを出力します。 回帰を実行している場合に便利です
テストするか、他の自動テスト機械を使用します。

-v, -詳細
より冗長になります。 次のような、プログラムのさまざまな側面に関する追加情報を提供します。
ロードされた共有オブジェクト、使用された抑制、インストルメンテーションの進行状況
および実行エンジン、および異常な動作に関する警告。 オプションを繰り返す
詳細レベルを上げます。

--trace-children = [ディフォルト： 番号]
有効にすると、Valgrindは、 exec 　
電話。 これは、マルチプロセスプログラムに必要です。

Valgrindはの子にトレースすることに注意してください フォーク （そうしないのは難しいでしょう、
から フォーク プロセスの同一のコピーを作成します）、したがって、このオプションは間違いなくひどいです
名前付き。 しかし、のほとんどの子供たちは フォーク すぐに電話する exec とにかく。

--trace-children-skip = patt1、patt2、..。
このオプションは、次の場合にのみ効果があります。 --trace-children = yes が指定されています。 それは可能にします
スキップされる子供もいます。 このオプションは、カンマ区切りのパターンのリストを取ります。
Valgrindがトレースしてはならない子実行可能ファイルの名前。 パターンはかもしれません
メタ文字を含めますか？ および*は、通常の意味を持ちます。

これは、プロセスのツリーから関心のないブランチをプルーニングするのに役立ちます。
Valgrindで実行します。 ただし、使用する際は注意が必要です。 Valgrindがトレースをスキップするとき
実行可能ファイルに、その実行可能ファイルのトレースをスキップするだけでなく、スキップします
その実行可能ファイルの子プロセスのいずれかをトレースします。 言い換えれば、旗はしません
指定された実行可能ファイルでトレースを停止させるだけです。
指定された実行可能ファイルのいずれかをルートとするプロセスサブツリー全体。

--trace-children-skip-by-arg = patt1、patt2、..。
これはと同じです --trace-children-スキップ、XNUMXつの違いがあります：
子プロセスにトレースするかどうかは、子への引数を調べることによって行われます。
実行可能ファイルの名前ではなく、プロセス。

--child-silent-after-fork = [ディフォルト： 番号]
有効にすると、Valgrindは子のデバッグまたはログ出力を表示しません
から生じるプロセス フォーク 電話。 これにより、出力の混乱を少なくすることができます（ただし
より誤解を招く）子を作成するプロセスを処理する場合。 特に
と組み合わせて便利 --trace-children =。 このオプションの使用も強力です
XML出力を要求する場合に推奨されます（--xml = yes）、それ以外の場合はXML
子供と親が混同される可能性があり、通常は役に立たなくなります。

--vgdb = [ディフォルト： はい]
Valgrindは次の場合に「gdbserver」機能を提供します --vgdb = yes or --vgdb = full is
指定。 これにより、外部のGNUGDBデバッガーがプログラムを制御およびデバッグできるようになります
Valgrindで実行するとき。 --vgdb = full パフォーマンスにかなりのオーバーヘッドが発生しますが、
より正確なブレークポイントとウォッチポイントを提供します。 を使用したプログラムのデバッグを参照してください。
詳細な説明については、ValgrindのgdbserverとGDBを参照してください。

組み込みgdbserverが有効になっているが、gdbが現在使用されていない場合、vgdb
コマンドラインユーティリティは、シェルからValgrindに「監視コマンド」を送信できます。 The
Valgrindコアは、一連のValgrindモニターコマンドを提供します。 ツールはオプションでできます
ツール固有の監視コマンドを提供します。これは、ツール固有に文書化されています。
章。

--vgdb-error = [ディフォルト： 999999999]
Valgrind gdbserverが有効になっている場合は、このオプションを使用してください --vgdb = yes or --vgdb = full.
エラーを報告するツールは、「番号」エラーが報告されるのを待ってからフリーズします
プログラムとGDBに接続するのを待っています。 したがって、値はゼロになります
プログラムが実行される前にgdbserverが起動します。 これは
通常、実行前にGDBブレークポイントを挿入するために使用され、ツールでも機能します
Massifなどのエラーを報告しません。

--vgdb-stop-at = [ディフォルト： なし]
Valgrind gdbserverが有効になっている場合は、このオプションを使用してください --vgdb = yes or --vgdb = full.
Valgrind gdbserverは、エラーごとに呼び出されます。 --vgdb-エラー されている
報告。 さらに、Valgrindgdbserverに他のサーバーを呼び出すように依頼することもできます
次のいずれかの方法で指定されたイベント：

・XNUMXつ以上のカンマ区切りリスト スタートアップ 終了する ヴァルグリンダベグジット.

その価値 スタートアップ 終了する ヴァルグリンダベグジット それぞれgdbserverを呼び出すことを示します
プログラムが実行される前、プログラムの最後の命令の後、
Valgrindの異常終了（内部エラー、メモリ不足など）。

注意： スタートアップ 　 --vgdb-error = 0 両方ともValgrindgdbserverが呼び出されます
プログラムが実行される前。 NS --vgdb-error = 0 さらにあなたの原因になります
後続のすべてのエラーで停止するプログラム。

· を 完全なセットを指定します。 と同等です
--vgdb-stop-at = startup、exit、valgrindabexit.

· なし 空のセットの場合。

--track-fds = [ディフォルト： 番号]
有効にすると、Valgrindは終了時または終了時に開いているファイル記述子のリストを出力します
gdbservermonitorコマンドを介した要求 v.info open_fds。 各ファイルと一緒に
記述子は、ファイルが開かれた場所と詳細のスタックバックトレースが出力されます
ファイル名やソケットの詳細などのファイル記述子に関連します。

--time-stamp = [ディフォルト： 番号]
有効にすると、各メッセージの前に経過したウォールクロックが表示されます
起動からの時間。日、時間、分、秒、ミリ秒で表されます。

--log-fd = [ディフォルト： 2, 標準エラー]
Valgrindがすべてのメッセージを指定されたファイルに送信するように指定します
ディスクリプタ。 デフォルトの2は、標準エラーチャネル（stderr）です。 これは可能性があることに注意してください
Valgrindの出力は次のようになるため、クライアント自身のstderrの使用を妨害します。
クライアントがstderrに送信する出力とインターリーブされます。

--log-file =
Valgrindがすべてのメッセージを指定されたファイルに送信するように指定します。 の場合
ファイル名が空の場合、中止されます。 XNUMXつの特別なフォーマット指定子があります
ファイル名に使用できます。

%p 現在のプロセスIDに置き換えられます。 これは、次のようなプログラムに非常に役立ちます
複数のプロセスを呼び出します。 警告：使用する場合 --trace-children = yes そしてあなたのプログラム
後でexecを呼び出さずに、複数のプロセスまたはプログラムフォークを呼び出し、
この指定子（または %q 以下の指定子）、すべてからのValgrind出力
これらのプロセスはXNUMXつのファイルにまとめられ、混乱し、不完全になる可能性があります。

％q {FOO} 環境変数の内容に置き換えられます FOO。 もし {フー}
パーツの形状が正しくない場合、アボートが発生します。 この指定子が必要になることはめったにありませんが、非常に
特定の状況（MPIプログラムを実行している場合など）で役立ちます。 アイデアはあなたが
ジョブ内のプロセスごとに異なる設定になる変数を指定します。
例BPROC_RANKまたはMPIセットアップに適用可能なもの。 名前付きの場合
環境変数が設定されていない場合、アボートが発生します。 一部のシェルでは、 {
　 } 文字はバックスラッシュでエスケープする必要がある場合があります。

%% に置き換えられます %.

もし % 他の文字が続く場合、アボートが発生します。

ファイル名が相対ファイル名を指定している場合、それはプログラムのイニシャルに入れられます
作業ディレクトリ：これは、プログラムが開始したときの現在のディレクトリです。
フォーク後またはexec後の実行。 絶対ファイル名を指定する場合（つまり、
'/'）で始まり、そこに配置されます。

--log-socket =
Valgrindがすべてのメッセージを指定されたポートに送信する必要があることを指定します
指定されたIPアドレス。 ポートは省略できます。その場合、ポート1500が使用されます。 もし
指定されたソケットに接続できません。Valgrindは書き込みにフォールバックします
標準エラー（stderr）に出力します。 このオプションは、
valgrind-listenerプログラムと組み合わせて。 詳細については、を参照してください。
マニュアルの解説。

エラー関連 OPTIONS

これらのオプションは、Memcheckなどのエラーを報告できるすべてのツールで使用されますが、
Cachegrind。

--xml = [ディフォルト： 番号]
有効にすると、出力の重要な部分（ツールのエラーメッセージなど）が次のようになります。
プレーンテキストではなくXML形式。 さらに、XML出力はに送信されます
プレーンテキスト出力とは異なる出力チャネル。 したがって、XNUMXつも使用する必要があります
of --xml-fd, --xml ファイル or --xml-ソケット XMLの送信先を指定します。

重要度の低いメッセージはプレーンテキストで印刷されますが、XMLが
出力とプレーンテキスト出力は、異なる出力チャネルに送信されます（
プレーンテキストの出力は引き続きによって制御されます --log-fd, -ログファイル 　 --ログソケット)
これは問題を引き起こさないはずです。

このオプションは、Valgrindの出力を次のように消費するツールの作業を楽にすることを目的としています。
GUIフロントエンドなどの入力。 現在、このオプションはMemcheck、Helgrind、
DRDとSGcheck。 出力形式はファイルで指定されています
Valgrind4またはのソースツリーのdocs / internals / xml-output-protocol3.5.0.txt
後で。

XML出力を要求するときにGUIが渡すための推奨オプションは次のとおりです。 --xml = yes
XML出力を有効にするには、 --xml ファイル XML出力を（おそらくGUIで選択された）に送信する
ファイル、 -ログファイル プレーンテキスト出力をGUIで選択されたXNUMX番目のファイルに送信するには、
--child-silent-after-fork = yes, -q プレーンテキストの出力をクリティカルに制限する
Valgrind自体によって作成されたエラーメッセージ。 たとえば、指定されたものを読み取れなかった
抑制ファイルは重大なエラーメッセージとしてカウントされます。 このように、成功のために
テキスト出力ファイルを実行すると空になります。 しかし、それが空でない場合、それは含まれます
GUIユーザーが知っておくべき重要な情報。

--xml-fd = [ディフォルト： -1、 無効]
ValgrindがXML出力を指定されたファイル記述子に送信する必要があることを指定します。
と組み合わせて使用​​する必要があります --xml = yes.

--xml-file =
ValgrindがXML出力を指定されたファイルに送信する必要があることを指定します。 それは違いない
と組み合わせて使用 --xml = yes。 どれか %p or %q ファイル名に表示されるシーケンス
とまったく同じ方法で展開されます -ログファイル。 説明を参照してください
of -ログファイル より詳細をご確認いただけます。

--xml-socket =
ValgrindがそのXML出力を指定されたポートで指定されたポートに送信する必要があることを指定します
IPアドレス。 と組み合わせて使用​​する必要があります --xml = yes。 引数の形式は次のとおりです。
によって使用されるものと同じ --ログソケット。 の説明を参照してください --ログソケット さらなる
詳細。

--xml-user-comment =
XML出力の先頭に追加のユーザーコメント文字列を埋め込みます。 次の場合にのみ機能します
--xml = yes 指定されています。 それ以外の場合は無視されます。

--demangle = [ディフォルト： はい]
C ++名の自動デコード（デコード）を有効/無効にします。 デフォルトで有効になっています。 いつ
有効にすると、ValgrindはエンコードされたC ++名を何かに変換しようとします
オリジナルに近づいています。 デマングラーは、g ++バージョン2.Xによってマングルされたシンボルを処理します。
3.Xおよび4.X。

デマングリングに関する重要な事実は、抑制で言及されている関数名です
ファイルはマングル形式である必要があります。 Valgrindは、次の場合に関数名をデマングルしません
該当する抑制を検索します。そうしないと抑制が発生するためです。
Valgrindの解きほぐし機械の状態に依存し、また遅いファイルの内容
ダウンサプレッションマッチング。

--num-callers = [ディフォルト： 12]
プログラムを識別するスタックトレースに表示されるエントリの最大数を指定します
場所。 エラーは、上位XNUMXつの関数の場所のみを使用して一般化されることに注意してください
（現在の関数内の場所、およびそのXNUMXつの直接の呼び出し元の場所）。 したがって、この
報告されるエラーの総数には影響しません。

この最大値は500です。設定を高くすると、Valgrindが実行されることに注意してください。
もう少しゆっくりと少し多くのメモリを消費しますが、
深くネストされたコールチェーンを持つプログラム。

--unw-stack-scan-thresh = [ディフォルト： 0] , --unw-stack-scan-frames = [ディフォルト：
5]
スタックスキャンのサポートは、ARMターゲットでのみ使用できます。

これらのフラグは、スタックスキャンによるスタックの巻き戻しを有効にして制御します。 通常の場合
スタック巻き戻しメカニズム-DwarfCFIレコードの使用、およびフレームポインターのフォロー
-失敗すると、スタックスキャンでスタックトレースを回復できる場合があります。

スタックスキャンは不正確でヒューリスティックなメカニズムであり、非常に
誤解を招く結果、またはまったくない。 通常の場合、緊急時にのみ使用する必要があります
巻き戻しは失敗しますが、それでもスタックトレースを保持することが重要です。

スタックスキャンは単純な手法です。アンワインダーはスタックから単語を読み取り、
それらがリターンアドレスであるかどうかを確認することにより、それらのどれがリターンアドレスであるかを推測しようとします
ARMまたはThumb呼び出し命令の直後をポイントします。 もしそうなら、単語はに追加されます
バックトレース。

主な危険は、関数呼び出しが戻りアドレスを残して戻るときに発生します
公開され、新しい関数が呼び出されますが、新しい関数は古い関数を上書きしません
住所。 この結果、バックトレースに関数のエントリが含まれる可能性があります
すでに戻ってきたので、非常に混乱します。

この実装の4番目の制限は、ページ（XNUMXKB、
通常）開始スタックポインタを含みます。 スタックフレームが大きい場合、これは
トレースに存在するのはごくわずか（またはまったくない）になる可能性があります。 また、あなたが
運が悪く、含まれているページの終わり近くに最初のスタックポインタがあります。
スキャンはすべての興味深いフレームを見逃す可能性があります。

デフォルトでは、スタックスキャンは無効になっています。 通常の使用例は、次の場合にそれを要求することです。
そうしないと、スタックトレースは非常に短くなります。 したがって、それを有効にするには、
--unw-stack-scan-thresh = number。 これにより、Valgrindはスタックスキャンを使用して
数未満のフレームを含むスタックトレースを「拡張」します。

スタックスキャンが実行される場合、生成されるのは最大でフレーム数のみです。
--unw-stack-scan-framesで指定されます。 通常、スタックスキャンは非常に多くの
この値がデフォルトで低い値（5）に設定されているガベージエントリ。 いかなる場合も
--num-callersで指定された値よりも大きいスタックトレースが作成されます。

--error-limit = [ディフォルト： はい]
有効にすると、Valgrindは合計10,000,000、つまり1,000を超えるとエラーの報告を停止します
別のものが見られました。 これは、エラー追跡機構を停止するためのものです。
多くのエラーがあるプログラムでは、パフォーマンスのオーバーヘッドが非常に大きくなります。

--error-exitcode = [ディフォルト： 0]
Valgrindがエラーを報告した場合に返す代替の終了コードを指定します
走る。 デフォルト値（ゼロ）に設定すると、Valgrindからの戻り値は常に
シミュレートされているプロセスの戻り値です。 ゼロ以外の値に設定すると、
Valgrindがエラーを検出した場合、代わりに値が返されます。 これは使用するのに便利です
自動テストスイートの一部としてのValgrindは、テストの検出を容易にします。
リターンコードを調べるだけで、Valgrindがエラーを報告したケース。

-エラーマーカー= 、 [ディフォルト： なし]
エラーがプレーンテキストとして出力される場合（つまり、XMLが使用されない場合）、 -エラーマーカー に指示します
を含む行を出力します 始まる (end）各エラーの前（後）の文字列。

このようなマーカーラインは、エラーの検索やエラーの抽出を容易にします。
プログラム出力と混合されたvalgrindエラーを含む出力ファイル。

空のマーカーが受け入れられることに注意してください。 したがって、開始（または終了）マーカーのみを使用するのは
可能。

--sigill-diagnostics = [ディフォルト： はい]
不正な命令診断の印刷を有効/無効にします。 デフォルトで有効になっていますが、
デフォルトでは無効になっています - 静かな 与えられます。 デフォルトは常に明示的にすることができます
このオプションを指定するとオーバーライドされます。

有効にすると、警告メッセージがいくつかの診断とともに出力されます。
Valgrindがデコードまたは変換できない命令が発生した後、
プログラムにはSIGILL信号が与えられます。 多くの場合、違法な指示はバグを示します
Valgrindの特定の命令に対するプログラムまたはサポートの欠如。 しかし、いくつかの
プログラムは、欠落してトラップする可能性のある命令を意図的に実行しようとします
プロセッサ機能を検出するためのSIGILL信号。 このフラグを使用すると、次のことが可能になります。
このような場合に得られる診断出力は避けてください。

--show-below-main = [ディフォルト： 番号]
デフォルトでは、エラーのスタックトレースには、下に表示される関数は表示されません。 メイン
ほとんどの場合、それは面白くないCライブラリのものやgobbledygookだからです。
または、 メイン スタックトレースに存在しない場合、スタックトレースは表示されません
以下の機能 メイン-glibcなどの関数のようなもの __libc_start_main.
さらに、もし メイン-同様の関数がトレースに存在し、次のように正規化されます
（未満 主要）、出力をより決定論的にするため。

このオプションを有効にすると、すべてのスタックトレースエントリが表示され、 メイン状
関数は正規化されません。

--fullpath-after = [ディフォルト： しない 表示する source パス]
デフォルトでは、Valgrindはスタックトレースのファイル名のみを表示し、へのフルパスは表示しません
ソースファイル。 ソースが存在する大規模なプロジェクトでValgrindを使用する場合
複数の異なるディレクトリ、これは不便な場合があります。 --fullpath-後 提供
この問題に対する柔軟な解決策。 このオプションが存在する場合、それぞれへのパス
ソースファイルが表示されますが、次の非常に重要な注意事項があります。 string にある
パス、それからまでのパス string 省略されている場合は、パスが表示されます
変更なし。 ご了承ください string パスのプレフィックスである必要はありません。

たとえば、/ home / janedoe / blah / src / foo / bar /xyzzy.cという名前のファイルについて考えてみます。 指定する
--fullpath-after = / home / janedoe / blah / src / Valgrindに名前を次のように表示させます
foo / bar /xyzzy.c。

文字列はプレフィックスである必要がないため、 --fullpath-after = src / 生成されます
同じ出力。 これは、パスに任意のマシン生成が含まれている場合に役立ちます
文字。 たとえば、パス/ my / build / dir / C32A1B47 / blah / src / foo / xyzzyは次のようになります。
を使用してfoo / xyzzyに剪定 --fullpath-after = / blah / src /.

単にフルパスを表示したい場合は、空の文字列を指定するだけです。
--fullpath-after =。 これは特別な場合ではなく、単に論理的な結果です。
上記のルール。

最後に、あなたが使用することができます --fullpath-後 複数回。 それの出現は原因になります
Valgrindは、フルパスの生成と上記のフィルタリングルールの適用に切り替えます。 各
生成されたパスは、すべての --fullpath-後-指定された文字列
指定された順序。 一致する最初の文字列により、パスは次のように切り捨てられます。
上記の。 一致するものがない場合は、フルパスが表示されます。 これにより、切り刻みが容易になります
ソースが多数の無関係なディレクトリから取得される場合のプレフィックス。

--extra-debuginfo-path = [ディフォルト： 未定義 　 未使用]
デフォルトでは、Valgrindはいくつかのよく知られたパスでデバッグオブジェクトを検索します。
/ usr / lib / debug /。

ただし、デバッグオブジェクトを
モバイルデバイスでValgrindを実行する場合の外部ストレージなどの任意の場所
ローカルストレージが限られています。 別の例はあなたが持っていない状況かもしれません
実行しているシステムにデバッグオブジェクトパッケージをインストールする権限
Valgrind。

これらのシナリオでは、追加の最終的な場所として絶対パスを提供できます。
Valgrindは、次のように指定してデバッグオブジェクトを検索します
--extra-debuginfo-path = / path / to / debug / objects。 指定されたパスが前に追加されます
検索対象オブジェクトの絶対パス名。 たとえば、Valgrindが探している場合
/w/x/y/zz.soおよび --extra-debuginfo-path = / a / b / c 指定された場合、
/a/b/c/w/x/y/zz.soでデバッグオブジェクトを探します。

このフラグはXNUMX回だけ指定する必要があります。 複数回指定した場合は、
最後のインスタンスは光栄です。

--debuginfo-server = ipaddr：port [ディフォルト： 未定義 　 未使用]
これは、バージョン3.9.0で導入された新しい実験的な機能です。

一部のシナリオでは、に保存されているオブジェクトからdebuginfoを読み取ると便利な場合があります。
別のマシン。 このフラグを使用すると、Valgrindはで実行されているdebuginfoサーバーにクエリを実行します
ローカルでdebuginfoオブジェクトが見つからない場合は、ipaddrとポートポートでリッスンします
ファイルシステム。

debuginfoサーバーは、ポートポートでTCP接続を受け入れる必要があります。 debuginfoサーバーは
ソースファイルauxprogs / valgrind-di-server.cに含まれています。 それはからのみ提供されます
それが開始されたディレクトリ。ポートは、クライアントとサーバーの両方でデフォルトで1500になります。
指定されていない。

Valgrindがdebuginfoサーバーを使用して/w/x/y/zz.soのdebuginfoを検索する場合、
パス名コンポーネントを削除し、サーバーでzz.soを要求するだけです。 それで
turnは、現在の作業ディレクトリでのみ、一致するdebuginfoオブジェクトを探します。

debuginfoデータは、Valgrindの要求に応じて、小さなフラグメント（8 KB）で送信されます。
各ブロックはLZOを使用して圧縮され、送信時間を短縮します。 実装には
シングルステージ802.11g（WiFi）ネットワークリンクで最高のパフォーマンスが得られるように調整されています。

GNU debuglink CRCを使用して、プライマリオブジェクトとデバッグオブジェクトの一致をチェックすることに注意してください。
スキームは、debuginfoサーバーを使用している場合でも実行されます。 このようなチェックを無効にするには、
--allow-mismatched-debuginfo = yesも指定する必要があります。

デフォルトでは、Valgrindビルドシステムはターゲットのvalgrind-di-serverをビルドします
プラットフォーム、これはほぼ間違いなくあなたが望むものではありません。 これまでのところ、私たちはできませんでした
automake / autoconfを取得してビルドプラットフォーム用にビルドする方法をご覧ください。 お望みならば
使用するには、上部に表示されているコマンドを使用して手動で再コンパイルする必要があります
auxprogs /valgrind-di-server.c。

--allow-mismatched-debuginfo = no | yes [番号]
個別のdebuginfoオブジェクトからdebuginfoを読み取る場合、Valgrindはデフォルトでチェックします
GNU debuglinkメカニズムを使用して、mainオブジェクトとdebuginfoオブジェクトが一致すること。 この
古いdebuginfoオブジェクトからdebuginfoを読み取らないことを保証します。
また、不一致の結果としてValgrindがクラッシュしないようにします。

このチェックは、-allow-mismatched-debuginfo = yesを使用してオーバーライドできます。 これは
debuginfoとメインオブジェクトが適切な方法で分割されていない場合に役立ちます。 なれ
ただし、これを使用する場合は注意が必要です。すべての整合性チェックが無効になり、Valgrindが無効になります。
mainオブジェクトとdebuginfoオブジェクトが一致しない場合にクラッシュすることが確認されています。

--suppressions = [ディフォルト： $ PREFIX / lib / valgrind / default.supp]
抑制するエラーの説明を読み取るための追加ファイルを指定します。 してもいいです
最大100個の追加の抑制ファイルを使用します。

--gen-suppressions = [ディフォルト： 番号]
に設定されている場合 はい、Valgrindは、エラーが表示されるたびに一時停止し、次の行を出力します。

----印刷抑制？ --- [リターン/ N / n / Y / y / C / c] ----

押します Retまたは N Ret or n Ret、Valgrindが印刷せずに実行を継続するようにします
このエラーの抑制。

押します Y Ret or y Ret Valgrindにこのエラーの抑制を書き込みます。 あなたはできる
次に、それについて聞きたくない場合は、それを切り取って抑制ファイルに貼り付けます。
将来のエラー。

に設定されている場合 を、Valgrindは、報告されたすべてのエラーに対して抑制を出力します。
ユーザーにクエリを実行します。

このオプションは、C ++プログラムで印刷されるため、特に便利です。
必要に応じて、名前が壊れた抑制。

印刷される抑制は可能な限り具体的であることに注意してください。 あなたは共通したいかもしれません
関数名にワイルドカードを追加し、フレームレベルを使用して、類似したものを作成します
ワイルドカード。 ワイルドカード機能は強力でありながら柔軟性があり、
注意深く編集すれば、関連するエラーのファミリー全体を抑制できる可能性があります。
ほんの少しの抑制。

XNUMXつの異なるエラーが同じ抑制によって抑制される場合があります。その場合
Valgrindは抑制を複数回出力しますが、必要なのはXNUMXつだけです。
抑制ファイルをコピーします（ただし、複数ある場合でも問題は発生しません）。 また、
抑制名は次のように与えられます; 名前はしません
本当に重要なのは、 -v 使用されているすべての抑制を出力するオプション
レコード。

--input-fd = [ディフォルト： 0, 標準入力]
使用時 --gen-suppressions = yes、Valgrindはキーボード入力を読み取るために停止します
各エラーが発生したときにあなたから。 デフォルトでは、標準入力（stdin）から読み取ります。
これは、stdinを閉じるプログラムにとって問題です。 このオプションを使用すると、
入力を読み取るための代替ファイル記述子。

--dsymutil = no | yes [はい]
このオプションは、Mac OSXでValgrindを実行している場合にのみ関係します。

Mac OS Xは、遅延デバッグ情報（debuginfo）リンクスキームを使用します。 オブジェクトの場合
debuginfoを含むファイルは、.dylibまたは実行可能ファイルにリンクされています。debuginfoは
最終ファイルにはコピーされません。 代わりに、debuginfoは手動でリンクする必要があります
実行可能ファイルまたは.dylibで、システム提供のユーティリティであるdsymutilを実行します。 NS
結果として結合されたdebuginfoは、実行可能ファイルまたは
.dylibですが、拡張子は.dSYMです。

自律的AI --dsymutil = no、Valgrindは、.dSYMディレクトリが次のいずれかである場合を検出します
欠落しているか、存在しているが、関連する実行可能ファイルと一致していないように見える、または
.dylib、おそらくそれが古くなっているためです。 このような場合、Valgrindは
警告メッセージが表示されますが、それ以上のアクションは実行しないでください。

自律的AI --dsymutil = yes、Valgrindは、このような場合、dsymutilを次のように自動的に実行します。
debuginfoを最新にするために必要です。 すべての実用的な目的のために、あなたがいつもなら
つかいます --dsymutil = yes、その後、dsymutilを手動または一部として実行する必要はありません。
Valgrindが必要に応じて実行するため、アプリケーションのビルドシステムの

Valgrindは、の実行可能ファイルまたはライブラリでdsymutilを実行しようとはしません。 / usr /,
/ 置き場 /, / sbin /, / opt /、/ sw /、/ System /、/ Library /、または/ Applications /（dsymutilは
そのような状況では常に失敗します。 そのようなのdebuginfoのために両方とも失敗します
プレインストールされたシステムコンポーネントはどこでも利用できません。
これらのディレクトリへの書き込み権限が必要です。

使用するときは注意してください --dsymutil = yes、既存の.dSYMが発生するため
サイレントに削除および再作成されるディレクトリ。 また、dsymutilはかなり
遅い、時には過度にそう。

--max-stackframe = [ディフォルト： 2000000]
スタックフレームの最大サイズ。 スタックポインタがこの量を超えて移動した場合
次に、Valgrindは、プログラムが別のスタックに切り替わっていると想定します。

プログラムに大きなスタック割り当て配列がある場合は、このオプションを使用する必要がある場合があります。
Valgrindは、プログラムのスタックポインタを追跡します。 それ以上に変化した場合
しきい値の量、Valgrindは、プログラムが別のスタックに切り替わっていると想定し、
Memcheckは、スタックポインタの変更が
しきい値。 通常、このヒューリスティックはうまく機能します。 ただし、プログラムが大規模に割り当てる場合
スタック上の構造、このヒューリスティックはだまされ、Memcheckはその後
多数の無効なスタックアクセスを報告します。 このオプションを使用すると、
別の値へのしきい値。

Valgrindのデバッグ出力で次のように指示された場合にのみ、このオプションの使用を検討する必要があります。
そうする。 その場合、指定する必要のある新しいしきい値が表示されます。

一般に、スタックに大きな構造を割り当てることはお勧めできません。
特にメモリが限られているシステムや、
それぞれが小さなスタックで多数のスレッドをサポートすることを期待します。
Memcheckによって実行されるエラーチェックは、ヒープに割り当てられたデータに対してより効果的です。
スタックに割り当てられたデータよりも。 このオプションを使用する必要がある場合は、
スタックではなくヒープに割り当てるようにコードを書き直すことを検討してください。

--main-stacksize = [ディフォルト： つかいます 現在 'ulimit' 価値]
メインスレッドのスタックのサイズを指定します。

メモリ管理を簡素化するために、Valgrindはメインに必要なすべてのスペースを予約します
起動時のスレッドのスタック。 つまり、で必要なスタックサイズを知る必要があります
スタートアップ

デフォルトでは、Valgrindはスタックサイズに現在の「ulimit」値、つまり16MBを使用します。
どちらか低い方。 多くの場合、これによりスタックサイズは8〜16MBの範囲になります。
ほとんどのアプリケーションでオーバーフローすることはほとんどありません。

より大きな合計スタックサイズが必要な場合は、 --メインスタックサイズ それを指定します。 設定するだけ
必要以上のスペース（つまり、数百）を予約するため、必要な高さ
必要以上のメガバイト）Valgrindのメモリアロケータを制約し、
Valgrindが使用できるメモリの総量を減らします。 これは本当に
32ビットマシンでの重要性。

Linuxでは、最大2GBのサイズのスタックをリクエストできます。 Valgrindは
スタックを割り当てることができない場合の診断メッセージ。

--メインスタックサイズ プログラムの初期スレッドのスタックサイズにのみ影響します。 それは持っています
Valgrindはスレッドスタックを割り当てないため、スレッドスタックのサイズには関係ありません。

両方を使用する必要があるかもしれません --メインスタックサイズ 　 --max-スタックフレーム 一緒。 です
それを理解することが重要 --メインスタックサイズ 最大合計スタックサイズを設定します。
一方 --max-スタックフレーム XNUMXつのスタックフレームの最大サイズを指定します。 あなたはするであろう
解決する必要があります --メインスタックサイズ あなた自身のための価値（通常、あなたの場合
アプリケーションsegfaults）。 しかし、Valgrindは必要なものを教えてくれます --max-スタックフレーム サイズ、
必要であれば。

の説明でさらに説明されているように --max-スタックフレーム、大規模な要件
スタックは、潜在的な移植性の問題の兆候です。 すべてを配置することをお勧めします
ヒープに割り当てられたメモリ内の大きなデータ。

--max-threads = [ディフォルト： 500]
デフォルトでは、Valgrindは最大500スレッドまで処理できます。 時折、その数も
小さな。 このオプションを使用して、別の制限を提供します。 例：-max-threads = 3000。

MALLOC（）-関連 OPTIONS

独自のバージョンのmallocを使用するツール（Memcheck、Massif、Helgrind、DRDなど）の場合、
以下のオプションが適用されます。

--alignment = [ディフォルト： 8 or 16、 依存 on 　 プラットホーム]
デフォルトではValgrindの malloc関数, 再割り当て、など、開始アドレスがであるブロックを返します
8バイト整列または16バイト整列（値はプラットフォームによって異なり、
プラットフォームのデフォルト）。 このオプションを使用すると、別の配置を指定できます。 NS
提供される値は、デフォルト以上、以下である必要があります
4096であり、XNUMXの累乗である必要があります。

--redzone-size = [ディフォルト： 依存 on 　 道具]
Valgrindの malloc、 realloc、 など、各ヒープブロックの前後にパディングブロックを追加します
実行中のプログラムによって割り当てられます。 このようなパディングブロックは、レッドゾーンと呼ばれます。 The
レッドゾーンサイズのデフォルト値はツールによって異なります。 たとえば、Memcheckは
クライアントによって割り当てられた各ブロックの前後に最低16バイトを保護します。
これにより、最大16バイトのブロックアンダーランまたはオーバーランを検出できます。

レッドゾーンのサイズを大きくすると、より長い距離のオーバーランを検出できるようになります。
ただし、Valgrindが使用するメモリの量が増えます。 レッドゾーンのサイズを小さくすると、
Valgrindに必要なメモリを減らすだけでなく、検出の可能性を減らします
オーバー/アンダーランなので、お勧めしません。

珍しい OPTIONS

これらのオプションは、Valgrindの特定のあいまいな動作に影響を与えるため、すべてのツールに適用されます
芯。 ほとんどの人はそれらを使用する必要はありません。

--smc-check = [ディフォルト： すべて非ファイル の x86 / amd64 / s390x、
スタック の その他 アーチ]
このオプションは、Valgrindによる自己変更コードの検出を制御します。 チェックがない場合
プログラムがコードを実行し、それを新しいコードで上書きすると、完了します。
新しいコードを実行すると、Valgrindは作成した翻訳を引き続き実行します
古いコード。 これにより、誤った動作やクラッシュが発生する可能性があります。

「最新の」アーキテクチャー（x86、amd64、またはs390x以外のもの）の場合、デフォルト
is スタック。 これは、正しいプログラムが再確立するために明示的なアクションを実行する必要があるためです。
コード変更後のDIキャッシュコヒーレンス。 Valgrindはそのようなことを観察し、尊重します
アクション。その結果、自己変更コードはゼロで透過的に処理されます。
追加費用。

x86、amd64、およびs390xの場合、プログラムはハードウェアに次のことを通知する必要はありません。
必要なDIコヒーレンス同期。 したがって、デフォルトは すべて非ファイルをカバーする
匿名の（ファイルでバックアップされていない）mmap領域にコードを生成する通常のケース。

利用可能なXNUMXつの設定の意味は次のとおりです。 検出なし（なし),
スタック上の自己変更コードを検出します（これは、ネストされたものを実装するためにGCCによって使用されます
関数） （スタック）、どこでも自己変更コードを検出します（を）、および検出
ファイルベースのマッピングを除くすべての場所での自己変更コード（すべて非ファイル).

で実行 を Valgrindの速度が著しく低下します。 で実行 なし めったにありません
ほとんどのプログラムで動的に生成されるコードはごくわずかであるため、処理速度が向上します。
当学校区の VALGRIND_DISCARD_TRANSLATIONS クライアントリクエストはに代わるものです --smc-check = all
　 --smc-check = all-non-file より多くのプログラマーの努力が必要ですが、Valgrindは可能です
翻訳が必要な時期を正確に伝えることで、プログラムをより高速に実行します
作り直し。

--smc-check = all-non-file より安価ですが、より限定されたバージョンを提供します
--smc-check = all。 から発信されていない翻訳にチェックを追加します
ファイルに裏打ちされたメモリマッピング。 JITなどのコードを生成する一般的なアプリケーション
Webブラウザーでは、匿名のmmap領域にコードを生成しますが、「固定」コードは
ブラウザのは常にファイルベースのマッピングに存在します。 --smc-check = all-non-file 取り
この観察の利点は、チェックのオーバーヘッドを次のコードに制限することです。
JITによって生成される可能性があります。

--read-inline-info = [ディフォルト： 未満]
有効にすると、ValgrindはDWARF3からのインライン関数呼び出しに関する情報を読み取ります
デバッグ情報。 これにより、Valgrindの起動が遅くなり、より多くのメモリを使用するようになります（通常は
インライン化された各コード、6ワード、関数名用のスペース）、ただし結果は
より記述的なスタックトレースで。 3.10.0リリースでは、この機能が有効になっています
デフォルトでは、Linux、Android、およびSolarisターゲットのみ、およびツールのみ
Memcheck、Helgrind、DRD。 これは、いくつかのスタックトレースの例です。
--read-inline-info = no:

== 15380 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15380 == 0x80484EA：メイン（inlinfo.c：6）
== 15380 ==
== 15380 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15380 == 0x8048550：fun_noninline（inlinfo.c：6）
== 15380 == by 0x804850E：main（inlinfo.c：34）
== 15380 ==
== 15380 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15380 == 0x8048520：メイン（inlinfo.c：6）

そしてここに同じエラーがあります --read-inline-info = yes:

== 15377 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15377 == 0x80484EA：fun_d（inlinfo.c：6）
== 15377 == by 0x80484EA：fun_c（inlinfo.c：14）
== 15377 == by 0x80484EA：fun_b（inlinfo.c：20）
== 15377 == by 0x80484EA：fun_a（inlinfo.c：26）
== 15377 == by 0x80484EA：main（inlinfo.c：33）
== 15377 ==
== 15377 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15377 == 0x8048550：fun_d（inlinfo.c：6）
== 15377 == by 0x8048550：fun_noninline（inlinfo.c：41）
== 15377 == by 0x804850E：main（inlinfo.c：34）
== 15377 ==
== 15377 ==条件付きジャンプまたは移動は、初期化されていない値によって異なります
== 15377 == 0x8048520：fun_d（inlinfo.c：6）
== 15377 == by 0x8048520：main（inlinfo.c：35）

--read-var-info = [ディフォルト： 番号]
有効にすると、Valgrindは変数のタイプと場所に関する情報をから読み取ります
DWARF3デバッグ情報。 これにより、Valgrindの起動が大幅に遅くなり、使用できるようになります
かなり多くのメモリがありますが、それを利用できるツール用です（Memcheck、
Helgrind、DRD）より正確なエラーメッセージが表示される可能性があります。 たとえば、ここにあります
Memcheckによって発行されたいくつかの標準エラー：

== 15363 ==クライアントチェック要求中に初期化されていないバイトが見つかりました
== 15363 == 0x80484A9：croak（varinfo1.c：28）
== 15363 == by 0x8048544：main（varinfo1.c：55）
== 15363 ==アドレス0x80497f7はデータシンボル「global_i7」内の2バイトです
== 15363 ==
== 15363 ==クライアントチェック要求中に初期化されていないバイトが見つかりました
== 15363 == 0x80484A9：croak（varinfo1.c：28）
== 15363 == by 0x8048550：main（varinfo1.c：56）
== 15363 ==アドレス0xbea0d0ccはスレッド1のスタックにあります
== 15363 ==メインによって作成されたフレーム＃1（varinfo1.c：45）

そしてここに同じエラーがあります --read-var-info = yes:

== 15370 ==クライアントチェック要求中に初期化されていないバイトが見つかりました
== 15370 == 0x80484A9：croak（varinfo1.c：28）
== 15370 == by 0x8048544：main（varinfo1.c：55）
== 15370 ==場所0x80497f7はglobal_i0 [2]内の7バイトであり、
== 15370 == varinfo1.c：41で宣言されたグローバル変数
== 15370 ==
== 15370 ==クライアントチェック要求中に初期化されていないバイトが見つかりました
== 15370 == 0x80484A9：croak（varinfo1.c：28）
== 15370 == by 0x8048550：main（varinfo1.c：56）
== 15370 ==場所0xbeb4a0ccはローカル変数 "local"内の0バイトです
== 15370 == varinfo1.c：46で、スレッド1のフレーム＃1で宣言されています

--vgdb-poll = [ディフォルト： 5000]
メインループの一部として、Valgrindスケジューラーは、何らかのアクティビティがあるかどうかを確認するためにポーリングします
（外部コマンドやgdbからの入力など）はgdbserverで処理する必要があります。
このアクティビティポーリングは、指定された数の基本ブロックを実行した後に実行されます（または
与えられた基本ブロック数よりわずかに多い）。 この投票はかなり安いので、
デフォルト値は比較的低く設定されています。 vgdbの場合、この値をさらに減らすことができます
すべてのスレッドが（ほとんどのスレッドが
時間）システムコールでブロックされました。

--vgdb-shadow-registers = no | yes [ディフォルト： 番号]
gdbserverをアクティブにすると、ValgrindシャドウレジスタがGDBに公開されます。 これとともに、
Valgrindシャドウレジスタの値は、GDBを使用して調べたり変更したりできます。
シャドウレジスタの公開は、GDBバージョン7.1以降でのみ機能します。

--vgdb-prefix = [ディフォルト： / tmp / vgdb-pipe]
gdb / vgdbと通信するために、Valgrind gdbserverは3つのファイル（2つの名前付きFIFO）を作成します
およびmmap共有メモリファイル）。 プレフィックスオプションは、ディレクトリとプレフィックスを制御します
これらのファイルの作成のため。

--run-libc-freeres = [ディフォルト： はい]
このオプションは、LinuxでValgrindを実行している場合にのみ関係します。

GNU Cライブラリ（libc.so）、すべてのプログラムで使用され、メモリを割り当てることができます
独自の用途。 通常、プログラムの終了時にそのメモリを解放する必要はありません。
Linuxカーネルは、次の場合にすべてのプロセスリソースを再利用するため、意味がありません。
プロセスはとにかく終了するので、物事が遅くなるだけです。

glibcの作成者は、この動作がValgrindなどのリークチェッカーを引き起こすことに気づきました。
出口でリークチェックが行われるときに、glibcでリークを誤って報告する。 避けるために
これ、彼らは呼ばれるルーチンを提供しました __libc_freeres 特にglibcをリリースするため
割り当てられたすべてのメモリ。 したがって、Memcheckは実行を試みます __libc_freeres 出口で。

残念ながら、一部の非常に古いバージョンのglibcでは、 __libc_freeres 十分です
セグメンテーション違反を引き起こすバギー。 これは、Red Hat7.1で特に顕著でした。
したがって、このオプションは、の実行を禁止するために提供されています __libc_freeres。 もしあなたの
プログラムはValgrindで正常に実行されているようですが、終了時にsegfaultsが発生すると、
--run-libc-freeres = no おそらく誤った報告を犠牲にして、それを修正します
libc.soのスペースリーク。

--sim-hints = hint1、hint2、..。
でシミュレートされた動作をわずかに変更するその他のヒントをValgrindに渡します
非標準または危険な方法。奇妙な機能のシミュレーションに役立つ可能性があります。 に
デフォルトでは、ヒントは有効になっていません。 注意して使用してください！ 現在知られているヒントは次のとおりです。

· lax-ioctls： ioctlの処理については非常に緩慢にしてください。 唯一の仮定は、サイズが
正しい。 書き込み時にバッファ全体を初期化する必要はありません。
これがないと、奇妙なioctlが多数あるデバイスドライバーを使用する
コマンドは非常に面倒になります。

· ヒューズ対応： ブロックする可能性のある特定のシステムコールの特別な処理を有効にする
FUSEファイルシステムで。 これは、Valgrindをで実行するときに必要になる場合があります
XNUMXつのスレッドを使用してFUSEファイルシステムを管理するマルチスレッドプログラムと
そのファイルシステムにアクセスするための別のスレッド。

· enable-outer： 実行中のプログラムが
それ自体がValgrindです。

· no-inner-prefix： プレフィックスの印刷を無効にする > 各stdoutまたはstderrの前
外側のValgrindによって実行されている内側のValgrindの出力ライン。 これは便利です
外部/内部設定でValgrind回帰テストを実行する場合。 に注意してください
接頭辞 > 常に内部デバッグログ行の前に出力されます。

· no-nptl-pthread-stackcache： このヒントは、Valgrindを実行している場合にのみ関連します
Linux。

GNU glibc pthreadライブラリ（libpthread.so）、pthreadプログラムで使用されます。
pthreadスタックのキャッシュを維持します。 pthreadが終了すると、使用されるメモリ
pthreadスタックおよび一部のスレッドローカルストレージ関連のデータ構造はそうではありません
常に直接リリースされます。 このメモリはキャッシュに保持されます（特定のサイズまで）、
新しいスレッドが開始された場合に再利用されます。

このキャッシュにより、helgrindツールは誤検知の競合状態を報告します
helgrindは内部glibcを理解しないため、このキャッシュされたメモリのエラー
キャッシュ同期プリミティブ。 したがって、helgrindを使用する場合は、キャッシュを無効にします
特にスレッドを使用する場合、誤検知の競合状態を回避するのに役立ちます
ローカルストレージ変数（例： __スレッド 修飾子）。

memcheckツールを使用する場合、キャッシュを無効にすると、glibcが使用するメモリが確保されます。
__thread変数を処理するために、スレッドが終了すると直接解放されます。

注：Valgrindは、glibcスタックの内部知識を使用してキャッシュを無効にします
キャッシュの実装とpthreadのデバッグ情報を調べることによって
図書館。 したがって、この手法はやや壊れやすく、すべてのglibcで機能するとは限りません。
バージョン。 これは、さまざまなglibcバージョンで正常にテストされています（例：
さまざまなプラットフォームで2.11、2.16、2.18）。

· 緩いドア： （Solarisのみ）ドアのシステムコールの処理については非常に緩慢にしてください
認識されないドアファイル記述子。 フルバッファが必要ではありません
書き込み時に初期化されます。 これがないと、 リブドア（3LIB）機能
完全に独自のセマンティクスを使用すると、多数の誤検知が報告される可能性があります。

--fair-sched = [ディフォルト： 番号]
当学校区の -フェアスケジュール オプションは、Valgrindがシリアル化するために使用するロックメカニズムを制御します
スレッドの実行。 ロックメカニズムは、スレッドのスケジュール方法を制御します。
設定が異なれば、公平性とパフォーマンスの間のトレードオフも異なります。 にとって
Valgrindスレッドのシリアル化スキームとその影響に関する詳細
パフォーマンスとスレッドのスケジューリング。スケジューリングとマルチスレッドのパフォーマンスを参照してください。

・ 値 --fair-sched = yes フェアスケジューラをアクティブにします。 要するに、複数の場合
スレッドを実行する準備が整いました。スレッドはラウンドロビン方式でスケジュールされます。
このメカニズムは、すべてのプラットフォームまたはLinuxバージョンで使用できるわけではありません。 そうでない場合
利用可能、使用 --fair-sched = yes Valgrindはエラーで終了します。

この設定を実行している場合は、全体的な応答性が向上することがあります。
Valgrind上のインタラクティブなマルチスレッドプログラム（Webブラウザなど）。

・ 値 --fair-sched = try プラットフォームで利用可能な場合は、公平なスケジューリングをアクティブにします。
それ以外の場合は、自動的ににフォールバックします --fair-sched = no.

・ 値 --fair-sched = no 公平性を保証しないスケジューラーをアクティブにします
実行の準備ができているスレッド間ですが、一般的に最高のパフォーマンスを提供します。

--kernel-variant = Variant1、variant2、..。
デフォルトカーネルのマイナーバリアントから発生するシステムコールとioctlを処理します。
このプラットフォーム。 これは、ハッキングされたカーネルまたはカーネルモジュールで実行する場合に便利です。
たとえば、非標準のioctlをサポートします。 注意して使用してください。 そうしない場合
このオプションが何をするかを理解すれば、ほぼ確実にそれは必要ありません。 現在
既知のバリアントは次のとおりです。

· bproc：サポート sys_broc x86でのシステムコール。 これはBProcで実行するためのものです。
これは、ビルドに使用されることがある標準Linuxのマイナーバリアントです。
クラスター。

· アンドロイド-no-hw-tls：ARM用のAndroidエミュレーターの一部のバージョンは、
ハードウェアTLS（スレッドローカル状態）レジスタ、および起動時にValgrindがクラッシュします。 使用する
TLSのソフトウェアサポートを選択するためのこのバリアント。

· アンドロイド GPU sgx5xx：これを使用して、独自のioctlの処理をサポートします。
Androidデバイス上のGPUのPowerVRSGX5XXシリーズ。 これを選択しなかった場合、
安定性の問題を引き起こしますが、Memcheckが後に誤ったエラーを報告する可能性があります
プログラムはGPU固有のioctlを実行します。

· アンドロイド GPU アドレノ 3xx：同様に、これを使用してプロプライエタリの処理をサポートします
Androidデバイス上のGPUのQualcommAdreno3XXシリーズのioctl。

--merge-recursive-frames = [ディフォルト： 0]
平衡二分木実装などの一部の再帰的アルゴリズムは、次のように作成します。
多くの異なるスタックトレース。それぞれに呼び出しのサイクルが含まれています。 サイクルは次のように定義されます
ゼロ個以上の他のプログラムカウンターで区切られたXNUMXつの同一のプログラムカウンター値
値。 Valgrindは、これらすべてのスタックトレースを格納するために大量のメモリを使用する可能性があります。 これは
このようなスタックトレースに関心のない繰り返しが含まれていることを考慮すると、メモリの使用が不十分です。
持っている関数などのより興味深い情報の代わりに再帰呼び出し
再帰呼び出しを開始しました。

オプション --merge-recursive-frames = Valgrindに検出してマージするように指示します
最大サイズの再帰呼び出しサイクル フレーム。 そのようなサイクルが
検出されると、Valgrindはスタックトレースに一意のプログラムカウンターとしてサイクルを記録します。

値0（デフォルト）では、再帰的なコールのマージは発生しません。 値が1の場合、
単純な再帰アルゴリズムのスタックトレース（たとえば、階乗の実装）
折りたたまれます。 生成されたスタックトレースを折りたたむには、通常、値2が必要になります
二分木、クイックソートなどの再帰的アルゴリズムによって。より高い値は
より複雑な再帰的アルゴリズムに必要です。

注：再帰呼び出しは、プログラムカウンター値の分析によって検出されます。 ではない
関数名を調べることで検出されます。

--num-transtab-sectors = [ディフォルト： 6 の Android プラットフォーム、 16 の を その他]
Valgrindは、プログラムのマシンコードを小さな断片に変換して計測します
（基本ブロック）。 翻訳は、分割された翻訳キャッシュに保存されます
いくつかのセクション（セクター）に。 キャッシュがいっぱいの場合、
最も古い翻訳は空にされ、再利用されます。 これらの古い翻訳が再び必要になった場合は、
Valgrindは、対応するマシンコードを再変換して再計測する必要があります。
高価な。 プログラムの「実行命令」ワーキングセットが大きい場合、増加
セクターの数は、の数を減らすことによってパフォーマンスを向上させる可能性があります
再翻訳が必要です。 セクターはオンデマンドで割り当てられます。 割り当てられると、セクターは
ツールと値に応じて、解放されることはなく、かなりのスペースを占有します
of --avg-transtab-entry-size （Memcheckの場合、セクターあたり約40 MB）。 オプションを使用する
--stats = yes セクターによって使用されるメモリと
セクターの割り当てとリサイクル。

--avg-transtab-entry-size = [ディフォルト： 0, 意味 つかいます ツール 提供 ディフォルト]
翻訳された基本ブロックの平均サイズ。 この平均サイズは、寸法を記入するために使用されます
セクターのサイズ。 各ツールは、使用されるデフォルト値を提供します。 このデフォルト値の場合
が小さすぎると、翻訳セクターがすぐにいっぱいになります。 このデフォルトの場合
値が大きすぎると、変換セクターのメモリのかなりの部分が使用されなくなります。
基本ブロック変換の平均サイズはツールによって異なり、
ツールオプションによって異なります。 たとえば、memcheckオプション --track-origins = yes 増加
基本ブロック変換のサイズ。 つかいます --avg-transtab-entry-size 調整するには
メモリを獲得するため、または再翻訳が多すぎるのを避けるためのセクターのサイズ。

--aspace-minaddr = [ディフォルト： 依存 on 　 プラットホーム]
一部のシステムライブラリとの潜在的な競合を回避するために、Valgrindは
下のアドレス空間 --aspace-minaddr 値、ライブラリの場合に備えて予約しておく
特にこの領域のメモリを要求します。 したがって、いくつかの「悲観的な」値が推測されます
プラットフォームに応じてValgrindによって。 Linuxでは、デフォルトで、Valgrindは
通常、この完全なゾーンで競合がない場合でも、最初の64MB。 使用できます
オプション --aspace-minaddr メモリを大量に消費するアプリケーションにメリットをもたらす
このより低いメモリの多く。 一方、対立に遭遇した場合、増加します
aspace-minaddr値はそれを解決するかもしれません。 競合は通常、次のように現れます
アドレス空間の低範囲でのmmapの失敗。 提供されるアドレスはページである必要があります
位置合わせされ、0x1000（4KB）以上である必要があります。 のデフォルト値を見つけるには
プラットフォーム、valgrind -d -d date 2>＆1 |などを実行します。 grep -iminaddr。 値
0x10000（64KB）未満では、一部のディストリビューションで問題が発生することが知られています。

--valgrind-stacksize = [ディフォルト： 1MB]
スレッドごとに、Valgrindには独自の「プライベート」スタックが必要です。 これらのデフォルトサイズ
スタックの大部分はディメンション化されているため、ほとんどの場合は十分です。 の場合
サイズが小さすぎると、Valgrindはセグメンテーション違反になります。 セグフォールトする前に、警告が表示される場合があります
限界に近づいたときにValgrindによって生成されます。

オプションを使用する --valgrind-スタックサイズ そのような（ありそうもない）警告が生成された場合、または
セグメンテーション違反によりValgrindが死亡しました。 そのようなセグメンテーション違反は
巨大なC ++シンボルをデマングルするときに見られます。

アプリケーションが多くのスレッドを使用し、多くのメモリを必要とする場合、いくつかを得ることができます
オプションを使用してこれらのValgrindスタックのサイズを縮小することによるメモリ
--valgrind-スタックサイズ.

--show-emwarns = [ディフォルト： 番号]
有効にすると、Valgrindは特定の場合にCPUエミュレーションに関する警告を発します。
これらは通常、面白くありません。

--require-text-symbol =：sonamepatt：fnnamepatt
sonameが一致する共有オブジェクトの場合 ソナメパット プロセスにロードされ、
エクスポートするすべてのテキスト記号を調べます。 それらのどれも一致しない場合 fnamepatt、印刷
エラーメッセージを表示し、実行を中止します。 これにより、実行が確実に実行されるようになります
特定の共有オブジェクトに特定の関数名が含まれていない限り、続行しないでください。

両方 ソナメパット 　 fnamepatt 通常の使用で書くことができます ? 　 * ワイルドカード。 にとって
例： "：* libc.so *：foo？bar"。 コロン以外の文字を使用して区切ることができます
XNUMXつのパターン。 重要なのは、最初の文字と区切り文字だけです。
文字は同じです。 たとえば、上記の例は次のように書くこともできます
「Q * libc.so * Qfoo？bar」。 複数
--require-テキストシンボル フラグは許可されます。その場合、ロードされる共有オブジェクト
プロセスにそれらすべてに対してチェックされます。

これの目的は、マークアップされたライブラリの信頼できる使用をサポートすることです。 例えば、
GCCのバージョンがあるとします libgomp.so でマークアップされています
Helgrindをサポートするための注釈。 間違ったものをロードするのは簡単すぎて混乱しますが、
注釈なし libgomp.so アプリケーションに。 つまり、アイデアは次のとおりです。テキスト記号をに追加します。
たとえば、マークアップされたライブラリ annotated_for_helgrind_3_6、そしてフラグを与える
--require-text-symbol =：* libgomp * so *：annotated_for_helgrind_3_6 だからいつ libgomp.so
がロードされると、Valgrindはそのシンボルテーブルをスキャンし、シンボルが存在しない場合、実行は
マークアップされていないライブラリを黙って続行するのではなく、中止しました。 あなたに注意してください
シェルが拡大するのを防ぐために、フラグ全体を引用符で囲む必要があります * 　 ?
ワイルドカード。

--soname-synonyms = syn1 = pattern1、syn2 = pattern2、..。
共有ライブラリがロードされると、Valgrindはライブラリ内の関数をチェックします。
交換または包装する必要があります。 たとえば、Memcheckは関連するすべてのmallocを置き換えます
独自のバージョンを持つ関数（malloc、free、calloc、...）。 そのような代替品は
デフォルトでは、sonameが事前定義されたsonameと一致する共有ライブラリでのみ実行されます
パターン（例： libc.so * Linuxの場合）。 デフォルトでは、静的な置換は行われません。
リンクライブラリまたはtcmallocなどの代替ライブラリ用。 場合によっては、
交換が可能 --soname-同義語 XNUMXつの追加の同義語パターンを指定し、
交換の柔軟性。

現在、この柔軟性は、malloc関連の関数でのみ許可されています。
同義語 ソマロック。 この同義語は、標準の置換を行うすべてのツールで使用できます
malloc関連の関数（例：memcheck、massif、drd、helgrind、exp-dhat、
exp-sgcheck）。

・代替mallocライブラリ：代替のmalloc関連関数を置き換えます
sonameのライブラリ mymalloclib.so、オプションを与える
--soname-synonyms = somalloc = mymalloclib.so。 パターンを使用して複数のパターンに一致させることができます
ライブラリsonames。 例えば、 --soname-synonyms = somalloc = * tcmalloc * 一致します
tcmallocライブラリのすべてのバリアントのsoname（native、debug、profiled、..。
tcmallocバリアント）。

注：elf共有ライブラリのsonameは、readelfを使用して取得できます
ユーティリティ。

・静的にリンクされたライブラリの置換は、 NONEを パターン。
たとえば、 libtcmalloc.a、memcheckは次の場合に正しく機能します
オプションを与える --soname-synonyms = somalloc = NONE。 NONEパターンは
メインの実行可能ファイルと、sonameを持たない共有ライブラリに一致します。

・Linux用の「デフォルト」のFirefoxビルドを実行するには、JEMallocがにリンクされています。
メインの実行可能ファイル、使用 --soname-synonyms = somalloc = NONE.

デバッグ ヴァルグラインド OPTIONS

Valgrind自体をデバッグするためのいくつかのオプションもあります。 それらを使用する必要はありません
物事の通常の実行で。 リストを見たい場合は、 --ヘルプ-デバッグ オプションを選択します。

メムチェック OPTIONS

-リークチェック= [ディフォルト： まとめ]
有効にすると、クライアントプログラムの終了時にメモリリークを検索します。 に設定されている場合
要約、リークがいくつ発生したかを示します。 に設定されている場合 全体像を or はい、個々のリーク
オプションで指定されているように、詳細に表示されたり、エラーとしてカウントされたりします
--show-leak-kinds 　 --リークの種類のエラー.

--leak-resolution = [ディフォルト： 高い]
リークチェックを行うとき、Memcheckがどの程度異なると見なすかを決定します
複数のリークをXNUMXつにマージするためにバックトレースを同じにする
リークレポート。 に設定すると 低いです、最初のXNUMXつのエントリのみが一致する必要があります。 いつ の、 4つの
エントリは一致する必要があります。 いつ 高いです、すべてのエントリが一致する必要があります。

ハードコアリークのデバッグには、おそらく使用する必要があります --leak-resolution = high 一緒に
　 --num-callers = 40 またはいくつかのそのような多数。

なお、 -リーク解決 設定はMemcheckの検索機能には影響しません
リーク。 結果の表示方法を変更するだけです。

--show-leak-kinds = [ディフォルト： 明確な、可能性のある]
に表示するリークの種類を指定します 全体像を 次のいずれかの方法でリーク検索を実行します。

・XNUMXつ以上のカンマ区切りリスト 明確 間接的な 可能 到達可能.

· を 完全なセット（すべてのリークの種類）を指定します。 と同等です
--show-leak-kinds = definite、indirect、possible、reachable.

· なし 空のセットの場合。

--errors-for-leak-kinds = [ディフォルト： 明確な、可能性のある]
エラーとしてカウントするリークの種類を指定します 全体像を リーク検索。 The is
同様に指定 --show-leak-kinds

--leak-check-heuristics = [ディフォルト： 全て]
リーク検索中に使用されるリークチェックヒューリスティックのセットを指定します。 NS
ヒューリスティックは、ブロックへのどの内部ポインタがブロックを次のように見なすかを制御します
到達可能。 ヒューリスティックセットは、次のいずれかの方法で指定されます。

・XNUMXつ以上のカンマ区切りリスト 標準文字列 長さ64 新しい配列
複数の継承.

· を ヒューリスティックの完全なセットをアクティブ化します。 と同等です
--leak-check-heuristics = stdstring、length64、newarray、multipleinheritance.

· なし 空のセットの場合。

これらのヒューリスティックは、によって生成されたオブジェクトのレイアウトに依存していることに注意してください。
C ++コンパイラ。 それらはいくつかのgccバージョン（例えば4.4と4.7）でテストされています。 彼ら
他のC ++コンパイラでは正しく動作しない可能性があります。

--show-reachable = , --show-possibly-lost =
これらのオプションは、表示するリークの種類を指定する別の方法を提供します。

· --show-reachable = no --show-possibly-lost = yes に相当します
--show-leak-kinds = definite、possible.

· --show-reachable = no --show-possibly-lost = no に相当します
--show-leak-kinds = define.

· --show-reachable = yes に相当します --show-leak-kinds = all.

注意してください --show-possibly-lost = no 次の場合は効果がありません --show-reachable = yes 指定されています。

--undef-value-errors = [ディフォルト： はい]
Memcheckが未定義の値のエラーの使用を報告するかどうかを制御します。 これをに設定します いいえ if
未定義の値のエラーは見たくありません。 スピード違反の副作用もあります
Memcheckをいくらか上げます。

--track-origins = [ディフォルト： 番号]
Memcheckが初期化されていない値の原点を追跡するかどうかを制御します。 デフォルトでは、
そうではありません。つまり、初期化されていない値は
危険な方法で使用されているため、初期化されていない値がどこに来たのかを知ることはできません
から。 これにより、根本的な問題を突き止めることが困難になることがよくあります。

に設定されている場合 はい、Memcheckは、初期化されていないすべての値の原点を追跡します。
次に、初期化されていない値のエラーが報告されると、Memcheckは
値の原点。 起点は、次のXNUMXつの場所のいずれかになります。ヒープブロック、
スタック割り当て、クライアントリクエスト、またはその他のその他のソース（たとえば、
BRK).

ヒープブロックから発生した初期化されていない値の場合、Memcheckはブロックの場所を示します
割り当てられました。 スタック割り当てに由来する初期化されていない値の場合、Memcheck
どの関数が値を割り当てたかを知ることができますが、それ以上ではありません-通常は
関数の開始中括弧のソース位置を示します。 だからあなたはすべきです
関数のすべてのローカル変数が適切に初期化されていることを注意深く確認してください。

パフォーマンスのオーバーヘッド：起点の追跡にはコストがかかります。 Memcheckの速度を半分にし、
メモリ使用量を最低100MB、場合によってはそれ以上増やします。 それにもかかわらず、それはできます
初期化されていない原因を特定するために必要な労力を大幅に削減します
エラーを評価するため、より多くの実行を行っているにもかかわらず、プログラマーの生産性が向上することがよくあります。
ゆっくり。

精度：Memcheckは原点を非常に正確に追跡します。 非常に大きなスペースと時間を避けるため
オーバーヘッド、いくつかの近似が行われます。 可能性は低いですが、それは可能です
Memcheckは誤った出所を報告するか、出所を特定できません。

組み合わせに注意してください --track-origins = yes 　 --undef-value-errors = no is
無意味。 Memcheckは、起動時にこの組み合わせをチェックして拒否します。

--partial-loads-ok = [ディフォルト： はい]
Memcheckが32、64、128、および256ビットの自然に整列された負荷を処理する方法を制御します。
一部のバイトがアドレス指定可能で、他のバイトがアドレス指定できないアドレス。 いつ はい、 そのような
ロードによってアドレスエラーが発生することはありません。 代わりに、不正なものから発生したロードされたバイト
アドレスは初期化されていないものとしてマークされ、有効なアドレスに対応するものは
通常の方法で処理されます。

日時 いいえ、部分的に無効なアドレスからのロードは、からのロードと同じように扱われます
完全に無効なアドレス：不正なアドレスエラーが発行され、その結果
バイトは初期化済みとしてマークされます。

このように動作するコードは、ISO C / C ++標準に違反していることに注意してください。
壊れていると見なす必要があります。 可能であれば、そのようなコードを修正する必要があります。

--expensive-definedness-checks = [ディフォルト： 番号]
Memcheckがより正確であるが、より高価なものを採用するかどうかを制御します（時間
値の定義性をチェックするときのアルゴリズムを消費します。 デフォルト設定は
そうしないでください、そしてそれは通常十分です。 ただし、高度に最適化されたコードの場合
valgrindは時々誤って文句を言うかもしれません。 でvalgrindを呼び出す
--expensive-definedness-checks = yes 役立ちますが、パフォーマンスが低下します。 ランタイム
25％の劣化が観察されていますが、追加コストは
手元のアプリケーション。

--keep-stacktraces = alloc | free | alloc-and-free | alloc-then-free | none [ディフォルト：
割り当てと無料]
mallocおよび/またはfreeされたブロックのために保持するスタックトレースを制御します。

自律的AI 割り当て後解放、スタックトレースは割り当て時に記録され、関連付けられます
ブロックで。 ブロックが解放されると、XNUMX番目のスタックトレースが記録され、これが
割り当てスタックトレースを置き換えます。 その結果、関連する「解放後の使用」エラー
このブロックには、ブロックが解放された場所のスタックトレースのみを表示できます。

自律的AI 割り当てと無料、ブロックの割り当てと割り当て解除の両方のスタックトレース
保存された。 したがって、「解放後に使用」エラーは両方を表示し、エラーが発生する可能性があります
診断が簡単です。 に比べ 割り当て後解放、この設定はわずかに増加します
ブロックとしてのValgrindのメモリ使用には、XNUMXつではなくXNUMXつの参照が含まれています。

自律的AI 割り当てる、割り当てスタックトレースのみが記録（および報告）されます。 と 無料です。,
割り当て解除スタックトレースのみが記録（および報告）されます。 これらの値はやや
ValgrindのメモリとCPU使用率を減らします。 エラーによっては便利な場合があります
検索しているタイプと、それらを分析するために必要な詳細レベル。 にとって
たとえば、メモリリークエラーのみに関心がある場合は、記録するだけで十分です。
割り当てスタックトレース。

自律的AI なし、mallocおよびfree操作のスタックトレースは記録されません。 もしあなたの
プログラムは多くのブロックを割り当てたり、多くの異なるスタックから割り当て/解放したりします
トレースでは、これにより、必要なCPUやメモリが大幅に減少する可能性があります。 もちろん、少数です
ヒープブロックに関連するエラーの詳細が報告されます。

スタックトレースが記録されると、Valgrindはスタックトレースをメモリに保持することに注意してください
どのブロックからも参照されていない場合でも。 一部のプログラム（たとえば、再帰的
アルゴリズム）は、膨大な数のスタックトレースを生成できます。 Valgrindの使用量が多すぎる場合
そのような状況でのメモリ、あなたはオプションで必要なメモリを減らすことができます
--keep-スタックトレース および/またはオプションに小さい値を使用する --num-発信者.

--freelist-vol = [ディフォルト： 20000000]
クライアントプログラムがを使用してメモリを解放するとき 無料です。 （Cで）または削除（C ++）、そのメモリ
すぐに再割り当てできるようになるわけではありません。 代わりに、マークされています
アクセスできず、解放されたブロックのキューに配置されます。 目的は、
解放されたメモリが循環に戻る可能性があります。 この
Memcheckがブロックへの無効なアクセスを検出できる可能性が高くなります
それらが解放された後、かなりの期間。

このオプションは、キュー内のブロックの最大合計サイズをバイト単位で指定します。
デフォルト値はXNUMX万バイトです。 これを増やすと、合計金額が増えます
Memcheckによって使用されるメモリの量ですが、解放されたブロックの無効な使用を検出する可能性があります。
それ以外の場合は検出されません。

--freelist-big-blocks = [ディフォルト： 1000000]
解放されたブロックのキューからブロックを再割り当てできるようにする場合、
Memcheckは、優先的に、以上のサイズのブロックを再循環します。
--freelist-big-blocks。 これにより、大きなブロックを解放する（特に解放する）ことが保証されます
より大きなブロック --freelist-vol）すぐに再循環につながることはありません
フリーリスト内のすべて（または多く）の小さなブロック。 言い換えれば、このオプション
「小さな」ブロックのダングリングポインタを発見する可能性を高めます。
大きなブロックが解放されたとき。

値を0に設定すると、すべてのブロックがFIFO順に再循環されます。

-回避策-gcc296-バグ= [ディフォルト： 番号]
有効になっている場合、スタックポインタの下の少しの距離で読み取りと書き込みを行うと想定します
GCC 2.96のバグが原因であり、報告されません。 「小さな距離」は256です
デフォルトではバイト。 GCC 2.96は、一部の古いLinuxのデフォルトコンパイラであることに注意してください。
ディストリビューション（RedHat 7.X）であるため、このオプションを使用する必要がある場合があります。 次の場合は使用しないでください
実際のエラーが見落とされる可能性があるため、そうする必要はありません。 より良い代替案
このバグが修正された最新のGCCを使用することです。

3ビットでGCC4.Xまたは32.Xを使用する場合にも、このオプションを使用する必要がある場合があります。
PowerPCLinux。 これは、GCCが以下にアクセスすることがあるコードを生成するためです。
スタックポインタ、特に浮動小数点から整数への変換用。 この
32ビットのPowerPCELF仕様に違反しているため、
アクセス可能なスタックポインタの下の場所。

--show-mismatched-frees = [ディフォルト： はい]
有効にすると、Memcheckは、次の関数を使用してヒープブロックの割り当てが解除されていることを確認します。
割り当て機能と一致します。 つまり、それは期待しています 無料です。 割り当て解除に使用されます
によって割り当てられたブロック malloc関数, 削除 によって割り当てられたブロックの場合 NEW, delete [] の
によって割り当てられたブロック 新着[]。 不一致が検出された場合、エラーが報告されます。 これは
一部の環境では、一致しない関数で解放するため、一般的に重要です。
クラッシュを引き起こす可能性があります。

ただし、このような不一致を回避できないシナリオがあります。 その時
ユーザーはの実装を提供します NEW/新着[] その呼び出し malloc関数 และจาก 削除/delete []
その呼び出し 無料です。、およびこれらの関数は非対称にインライン化されています。 たとえば、想像してみてください
それ delete [] インラインですが 新着[] ではありません。 その結果、Memcheckはすべてを「見る」ことになります
delete [] への直接通話としての通話 無料です。、プログラムソースに含まれていない場合でも
不一致の呼び出し。

これにより、多くの紛らわしく無関係なエラーレポートが発生します。
--show-mismatched-frees = no これらのチェックを無効にします。 一般的にはお勧めできません
ただし、結果として実際のエラーを見逃す可能性があるため、これらを無効にします。

--ignore-ranges = 0xPP-0xQQ [、0xRR-0xSS]
このオプションにリストされているすべての範囲（および複数の範囲を指定できます。
カンマ）は、Memcheckのアドレス指定可能性チェックでは無視されます。

--malloc-fill =
malloc、newなどによって割り当てられたブロックを、callocではなく指定されたもので埋めます
バイト。 これは、あいまいなメモリ破損の問題を解決しようとするときに役立ちます。
割り当てられた領域は、Memcheckによって未定義と見なされます-このオプションのみ
その内容に影響します。 ご了承ください --malloc-fill 次の場合、メモリのブロックに影響を与えません
クライアントリクエストの引数として使用されますVALGRIND_MEMPOOL_ALLOCまたは
VALGRIND_MALLOCLIKE_BLOCK。

--free-fill =
free、deleteなどによって解放されたブロックを、指定されたバイト値で埋めます。 これは
あいまいなメモリ破損の問題を解決しようとするときに役立ちます。 解放された領域は
Memcheckはまだアクセスに無効と見なしています-このオプションは
コンテンツ。 ご了承ください -無料-塗りつぶし として使用される場合、メモリのブロックには影響しません
クライアント要求への引数VALGRIND_MEMPOOL_FREEまたはVALGRIND_FREELIKE_BLOCK。

キャッシュグラインド OPTIONS

--I1 = 、 、 サイズ>
レベル1命令キャッシュのサイズ、結合性、および行サイズを指定します。

--D1 = 、 、 サイズ>
レベル1データキャッシュのサイズ、結合性、および行サイズを指定します。

--LL = 、 、 サイズ>
最終レベルのキャッシュのサイズ、結合性、および行サイズを指定します。

--cache-sim = no | yes [はい]
キャッシュアクセスとミスカウントの収集を有効または無効にします。

--branch-sim = no | yes [番号]
分岐命令と誤予測カウントの収集を有効または無効にします。 沿って
デフォルトでは、これはCachegrindを約25％遅くするため、無効になっています。 ご了承ください
指定できません --cache-sim = no 　 --branch-sim = no 一緒に、それが去るであろうように
収集する情報がないCachegrind。

--cachegrind-out-file =
プロファイルデータをデフォルトの出力ファイルではなくファイルに書き込みます。
cachegrind.out。 。 The %p 　 %q フォーマット指定子を使用して、プロセスを埋め込むことができます
IDおよび/または名前の環境変数の内容（
コアオプション -ログファイル.

コールグラインド OPTIONS

--callgrind-out-file =
プロファイルデータをデフォルトの出力ファイルではなくファイルに書き込みます。
callgrind.out。 。 The %p 　 %q フォーマット指定子を使用して、プロセスを埋め込むことができます
IDおよび/または名前の環境変数の内容（
コアオプション -ログファイル。 複数のダンプが作成されると、ファイル名が変更されます
さらに遠く; 下記参照。

--dump-line = [ディフォルト： はい]
これは、イベントカウントをソースラインの粒度で実行する必要があることを指定します。
これにより、デバッグ情報を使用してコンパイルされたソースのソース注釈が可能になります
(-g).

--dump-instr = [ディフォルト： 番号]
これは、イベントのカウントを命令ごとの粒度で実行する必要があることを指定します。
これにより、アセンブリコードの注釈が可能になります。 現在、結果は表示のみ可能です
KCachegrindによる。

--compress-strings = [ディフォルト： はい]
このオプションは、プロファイルデータの出力形式に影響を与えます。 それはかどうかを指定します
文字列（ファイル名と関数名）は番号で識別する必要があります。 これにより、
ファイルですが、人間が読むのをより困難にします（これはどのファイルでも推奨されていません
場合）。

--compress-pos = [ディフォルト： はい]
このオプションは、プロファイルデータの出力形式に影響を与えます。 それはかどうかを指定します
数値位置は常に絶対値として指定されるか、
以前の数値と比較して。 これにより、ファイルサイズが縮小されます。

--combine-dumps = [ディフォルト： 番号]
有効にすると、複数のプロファイルデータパーツが生成される場合、これらのパーツは次のようになります。
同じ出力ファイルに追加されます。 推奨されません。

--dump-every-bb = [ディフォルト： 0, 一度もない]
プロファイルデータを毎回ダンプする カウント 基本ブロック。 ダンプが必要かどうかはチェックされるだけです
Valgrindの内部スケジューラーが実行されたとき。 したがって、有用な最小設定は
カウントは100000ビット値であり、長いダンプ期間を可能にします。

--dump-before =
入るときにダンプ function.

--zero-before =
入場時にすべての費用をゼロにする function.

--dump-after =
離れるときにダンプ function.

--instr-atstart = [ディフォルト： はい]
Callgrindでシミュレーションとプロファイリングを最初から開始するかどうかを指定します
プログラム。 noに設定すると、Callgrindは情報を収集できなくなります。
通話を含みますが、最大で約4の速度低下があります。これは最小値です。
Valgrindのオーバーヘッド。 インストルメンテーションは、callgrind_controlを介してインタラクティブに有効にできます
-私は。

結果のコールグラフにはおそらく含まれないことに注意してください メイン、しかし
インストルメンテーションが有効になった後に実行されるすべての機能が含まれます。 計装
プログラムで有効/無効にすることもできます。 Callgrindインクルードファイルcallgrind.hを参照してください
ソースコードで使用する必要のあるマクロの場合。

キャッシュシミュレーションの場合、インストルメンテーションをオンにすると、結果の精度が低下します
プログラムの実行の後半で、シミュレーターはその時点で空のキャッシュから開始します。
このエラーに対処するには、後でイベント収集をオンにします。

--collect-atstart = [ディフォルト： はい]
プロファイル実行の開始時にイベント収集を有効にするかどうかを指定します。

プログラムの一部だけを見るには、次のXNUMXつの可能性があります。

1.プロファイリングするプログラム部分に入る前にイベントカウンタをゼロにして、ダンプします
そのプログラム部分を離れた後、イベントはファイルにカウンターします。

2.必要に応じて収集状態のオン/オフを切り替えて、発生しているイベントカウンターのみを確認します
あなたがプロファイリングしたいプログラムパートの中にいる間。

XNUMX番目のオプションは、プロファイリングするプログラム部分がmanyと呼ばれる場合に使用できます。
回数。 オプション1、つまり大量のダンプを作成することは、ここでは実用的ではありません。

収集状態は、オプションを使用して、特定の関数の開始時と終了時に切り替えることができます
--トグル収集。 このオプションを使用する場合は、収集状態を無効にする必要があります。
始まり。 の仕様に注意してください --トグル収集 暗黙的に設定
--collect-state = no.

クライアントリクエストを挿入することでも、コレクションの状態を切り替えることができます
CALLGRIND_TOGGLE_COLLECT; 必要なコード位置で。

--toggle-collect =
の入口/出口でコレクションを切り替えます function.

--collect-jumps = [ディフォルト： 番号]
これは、（条件付き）ジャンプの情報を収集する必要があるかどうかを指定します。 として
上記のように、callgrind_annotateは現在データを表示できません。 あなたは使用する必要があります
KCachegrindは、注釈付きコードでジャンプ矢印を取得します。

--collect-systime = [ディフォルト： 番号]
これは、システムコール時間の情報を収集する必要があるかどうかを指定します。

--collect-bus = [ディフォルト： 番号]
これは、実行されたグローバルバスイベントの数を収集する必要があるかどうかを指定します。
これらのイベントには、イベントタイプ「Ge」が使用されます。

--cache-sim = [ディフォルト： 番号]
フルキャッシュシミュレーションを実行するかどうかを指定します。 デフォルトでは、命令の読み取りのみ
アクセスがカウントされます（「Ir」）。 キャッシュシミュレーションでは、さらにイベントカウンターがあります
有効：命令読み取り（ "I1mr" / "ILmr"）、データ読み取りアクセス（ "Dr"）でのキャッシュミス
および関連するキャッシュミス（ "D1mr" / "DLmr"）、データ書き込みアクセス（ "Dw"）および関連するキャッシュ
ミス（ "D1mw" / "DLmw"）。 詳細については、Cachegrind：キャッシュとブランチ-を参照してください。
予測プロファイラー。

--branch-sim = [ディフォルト： 番号]
分岐予測シミュレーションを実行するかどうかを指定します。 その他のイベントカウンターは
有効：実行された条件分岐と関連する予測子のミスの数
（ "Bc" / "Bcm"）、ジャンプアドレス予測子の間接ジャンプおよび関連するミスを実行しました
（ "Bi" / "Bim"）。

ヘルグラインド OPTIONS

--free-is-write = no | yes [ディフォルト： 番号]
有効にすると（デフォルトではない）、Helgrindはヒープメモリの解放をあたかも
空きの直前にメモリが書き込まれました。 これは、記憶がある場所でのレースを公開します
あるスレッドによって参照され、別のスレッドによって解放されますが、監視可能なものはありません
参照が解放される前に発生することを確認するための同期イベント。

この機能はValgrind3.7.0の新機能であり、実験的なものと見なされています。 です
カスタムメモリアロケータとの相互作用がないため、デフォルトでは有効になっていません
現在よく理解されています。 ユーザーからのフィードバックを歓迎します。

--track-lockorders = no | yes [ディフォルト： はい]
有効にすると（デフォルト）、Helgrindはロック順序の整合性チェックを実行します。 にとって
一部のバグのあるプログラムでは、報告されるロック順序エラーの数が多くなる可能性があります
特にレースエラーだけに興味がある場合は、迷惑です。 したがって、あなたは
ロック順序のチェックを無効にすると便利です。

--history-level = none | approx | full [ディフォルト： 満杯]
--history-level = full （デフォルト）Helgrindが
レースレポートでXNUMXつのスタックトレースを生成できる「古い」アクセス-両方のスタック
現在のアクセスのトレース、および古い競合するアクセスのトレース。 に
メモリ使用量を制限し、「古い」アクセススタックトレースは最大8エントリに制限されます。
たとえ --num-発信者 値が大きいです。

このような情報を収集することは、速度とメモリの両方で、特に
多くのスレッド間同期イベント（ロック、ロック解除など）を実行するプログラム。
そのような情報がなければ、人種の根本的な原因を突き止めることはより困難です。
それにもかかわらず、あなたがただチェックしたい状況ではそれを必要としないかもしれません
レースの有無、たとえば、回帰テストを行う場合
以前はレースフリーのプログラムでした。

--history-level = none 反対の極端です。 ヘルグラインドは何も収集しません
以前のアクセスに関する情報。 これは、よりも劇的に速くなる可能性があります
--history-level = full.

--history-level = approx これらのXNUMXつの極端の間の妥協点を提供します。 それが原因
後でアクセスするための完全なトレースとおおよその情報を表示するHelgrind
以前のアクセスに関して。 このおおよその情報は、XNUMXつのスタックで構成されています。
以前のアクセスは、プログラムポイント間のどこかで発生したことが保証されています
XNUMXつのスタックで示されます。 これは、の正確なスタックを表示するほど有用ではありません。
以前のアクセス（ --history-level = full します）、しかしそれは何もないよりはましです、そしてそれは
ほぼ同じくらい速い --history-level = none.

--conflict-cache-size = N [ディフォルト： 1000000]
このフラグは、 --history-level = full.

「古い」競合するアクセスに関する情報は、限られたサイズのキャッシュに保存されます。
LRUスタイルの管理を使用します。 これが必要なのは、
プログラムによって行われたすべての単一メモリアクセスのスタックトレース。 履歴情報
最近アクセスされていない場所では、スペースを解放するために定期的に破棄されます
キャッシュ。

このオプションは、異なるメモリの数に関して、キャッシュのサイズを制御します
競合するアクセス情報が保存されているアドレス。 あなたがそれを見つけたら
Helgrindは、予想されるXNUMXつのスタックではなくXNUMXつのスタックでレースエラーを示しています
スタックの場合は、この値を増やしてみてください。

最小値は10,000、最大値は30,000,000（デフォルトのXNUMX倍）です。
価値）。 値を1増やすと、Helgrindのメモリ要件が非常に増えます。
約100バイトなので、最大値は簡単にXNUMXギガバイト程度余分に消費されます
メモリの。

--check-stack-refs = no | yes [ディフォルト： はい]
デフォルトでは、Helgrindはプログラムによって行われたすべてのデータメモリアクセスをチェックします。 この旗
スレッドスタック（ローカル変数）へのアクセスのチェックをスキップできます。 これはできます
パフォーマンスは向上しますが、スタックに割り当てられたデータで競合が発生しないという犠牲が伴います。

--ignore-thread-creation = [ディフォルト： 番号]
スレッド作成中のすべてのアクティビティを無視するかどうかを制御します。 デフォルトでは
Solarisでのみ有効になります。 Solarisは、より高いスループット、並列処理、および
他のオペレーティングシステムよりもスケーラビリティがありますが、よりきめ細かいロックが必要です
アクティビティ。 これは、たとえば、スレッドがglibcで作成される場合、XNUMXつだけであることを意味します。
大きなロックはすべてのスレッド設定に使用されます。 Solaris libcは、いくつかのきめ細かいロックを使用します
作成者スレッドは、たとえば、
作成されたスレッドへのスタックとTLSセットアップシーケンス。 この状況はヘルグラインドを混乱させます
作成者と作成者の間に誤った順序があることを前提としているため
糸; したがって、アプリケーションの多くのタイプの競合状態はそうではありません
報告。 このような誤った順序付けを防ぐために、このコマンドラインオプションは次のようにyesに設定されます。
Solarisのデフォルト。 したがって、すべてのアクティビティ（ロード、ストア、クライアント要求）は無視されます
その間：

・作成者スレッドでのpthread_create（）呼び出し

・作成されたスレッドでのスレッド作成フェーズ（スタックとTLSのセットアップ）

また、スレッドの作成中に割り当てられた新しいメモリは追跡されません。つまり、レースレポートです。
そこで抑制されます。 DRDは暗黙的に同じことを行います。 これが必要なのは
Solaris libcは多くのオブジェクトをキャッシュし、それらをさまざまなスレッドに再利用します。
ヘルグラインドを混乱させます。

DRD OPTIONS

--check-stack-var = [ディフォルト： 番号]
DRDがスタック変数のデータ競合を検出するかどうかを制御します。 スタック変数の検証
ほとんどのプログラムはスタック変数を共有しないため、デフォルトでは無効になっています
スレッド。

--exclusive-threshold = [ディフォルト： オフ]
ミューテックスまたはライターロックが時間より長く保持されている場合は、エラーメッセージを出力します
ミリ秒単位で指定します。 このオプションを使用すると、ロックの競合を検出できます。

--join-list-vol = [ディフォルト： 10]
あるスレッドの終わりにあるステートメントと別のスレッドの間で発生するデータ競合
スレッドが持っている直後にメモリアクセス情報が破棄されると、見逃される可能性があります
参加しました。 このオプションを使用すると、結合されたスレッドのメモリの数を指定できます
アクセス情報は保持する必要があります。

--first-race-only = [ディフォルト： 番号]
メモリ位置で検出された最初のデータ競合のみを報告するかどうか
または、メモリ位置で検出されたすべてのデータ競合。

--free-is-write = [ディフォルト： 番号]
メモリへのアクセスとメモリの解放の間の競合を報告するかどうか。 これを有効にする
オプションを使用すると、DRDの実行がわずかに遅くなる可能性があります。 ノート：

・を使用するカスタムメモリアロケータを使用する場合は、このオプションを有効にしないでください。
VG_USERREQ__MALLOCLIKE_BLOCKおよびVG_USERREQ__FREELIKE_BLOCK
誤検知が発生します。

・参照カウントオブジェクトを使用する場合は、このオプションを有効にしないでください。
そのコードに適切な注釈が付けられている場合でも、誤検知が発生します
ANNOTATE_HAPPENS_BEFOREおよびANNOTATE_HAPPENS_AFTER。 たとえば、の出力を参照してください
例として次のコマンド：valgrind --tool = drd --free-is-write = yes
drd / tests / annotate_smart_pointer。

--report-signal-unlocked = [ディフォルト： はい]
通話を報告するかどうか pthread_cond_signal 　 pthread_cond_broadcast どこ
を介して信号に関連付けられているミューテックス pthread_cond_wait or
pthread_cond_timed_wait信号の送信時にはロックされていません。 信号を送信する
関連するミューテックスをロックしないと、一般的なプログラミングエラーが発生する可能性があります。
微妙な競合状態と予測できない動作を引き起こします。 いくつかの珍しいものがあります
ただし、同期パターンは、保持せずに信号を安全に送信できる場合
関連するミューテックスをロックします。

--segment-merging = [ディフォルト： はい]
セグメントのマージを制御します。 セグメントのマージは、メモリ使用量を制限するためのアルゴリズムです。
データレース検出アルゴリズム。 セグメントのマージを無効にすると、精度が向上する可能性があります
レースレポートに表示されるいわゆる「その他のセグメント」ですが、アウトをトリガーすることもできます
メモリエラーの。

--segment-merging-interval = [ディフォルト： 10]
指定された数の新しいセグメントが実行された後でのみ、セグメントのマージを実行します
作成した。 これは、次のいずれかを選択できる高度な構成オプションです。
低い値を選択するか、DRDの実行速度を上げることにより、DRDのメモリ使用量を最小限に抑えます。
少し高い値を選択します。 このパラメータの最適値は、
分析中のプログラム。 デフォルト値は、ほとんどのプログラムで適切に機能します。

--shared-threshold = [ディフォルト： オフ]
リーダーロックが指定された時間より長く保持された場合は、エラーメッセージを出力します
（ミリ秒単位）。 このオプションを使用すると、ロックの競合を検出できます。

--show-confl-seg = [ディフォルト： はい]
レースレポートに競合するセグメントを表示します。 この情報は見つけるのに役立つので
データ競合の原因であるため、このオプションはデフォルトで有効になっています。 このオプションを無効にすると、
DRDの出力がよりコンパクトになります。

--show-stack-usage = [ディフォルト： 番号]
スレッド終了時のスタック使用量を出力します。 プログラムが大量に作成する場合
スレッドに割り当てられる仮想メモリの量を制限することが重要になります
スレッドスタック。 このオプションを使用すると、スタックメモリの量を監視できます。
クライアントプログラムの各スレッドによって使用されます。 注：DRDツール自体がいくつかを割り当てます
クライアントスレッドスタック上の一時データ。 この一時データに必要なスペース
クライアントプログラムがスタックメモリを割り当てるときに割り当てる必要がありますが、そうではありません
DRDによって報告されたスタック使用量に含まれます。

--ignore-thread-creation = [ディフォルト： 番号]
スレッド作成中のすべてのアクティビティを無視するかどうかを制御します。 デフォルトでは
Solarisでのみ有効になります。 Solarisは、より高いスループット、並列処理、および
他のオペレーティングシステムよりもスケーラビリティがありますが、よりきめ細かいロックが必要です
アクティビティ。 これは、たとえば、スレッドがglibcで作成される場合、XNUMXつだけであることを意味します。
大きなロックはすべてのスレッド設定に使用されます。 Solaris libcは、いくつかのきめ細かいロックを使用します
作成者スレッドは、たとえば、
作成されたスレッドへのスタックとTLSセットアップシーケンス。 この状況はDRDを混乱させます
作成者と作成されたスレッドの間に誤った順序が設定されていることを前提としています。 と
したがって、アプリケーション内の多くの種類の競合状態は報告されません。 に
このような誤った順序付けを防ぐために、このコマンドラインオプションはデフォルトでyesに設定されています
Solaris。 したがって、すべてのアクティビティ（ロード、ストア、クライアント要求）は、次の期間中は無視されます。

・作成者スレッドでのpthread_create（）呼び出し

・作成されたスレッドでのスレッド作成フェーズ（スタックとTLSのセットアップ）

--trace-addr = [ディフォルト： なし]
指定されたアドレスのすべてのロードおよびストアアクティビティをトレースします。 このオプションは
複数回指定しました。

--ptrace-addr = [ディフォルト： なし]
指定されたアドレスのすべてのロードおよびストアアクティビティをトレースし、それを継続します
そのアドレスのメモリが解放され、再割り当てされた後。

--trace-alloc = [ディフォルト： 番号]
すべてのメモリ割り当てと割り当て解除をトレースします。 大量の出力を生成する可能性があります。

--trace-barrier = [ディフォルト： 番号]
すべてのバリアアクティビティをトレースします。

--trace-cond = [ディフォルト： 番号]
すべての条件変数アクティビティをトレースします。

--trace-fork-join = [ディフォルト： 番号]
すべてのスレッド作成およびすべてのスレッド終了イベントをトレースします。

--trace-hb = [ディフォルト： 番号]
ANNOTATE_HAPPENS_BEFORE（）、ANNOTATE_HAPPENS_AFTER（）、および
ANNOTATE_HAPPENS_DONE（）クライアント要求。

--trace-mutex = [ディフォルト： 番号]
すべてのミューテックスアクティビティをトレースします。

--trace-rwlock = [ディフォルト： 番号]
すべてのリーダーライターロックアクティビティをトレースします。

--trace-semaphore = [ディフォルト： 番号]
すべてのセマフォアクティビティをトレースします。

マシフ OPTIONS

--heap = [ディフォルト： はい]
ヒーププロファイリングを実行するかどうかを指定します。

--heap-admin = [ディフォルト： 8]
ヒーププロファイリングが有効になっている場合、ブロックあたりの管理バイト数を
使用する。 変動する可能性があるため、これは平均の見積もりである必要があります。 たとえば、
Linux上のglibcで使用されるアロケータには、ブロックあたり4〜15バイトが必要です。
さまざまな要因に応じて。 そのアロケータには、解放するための管理スペースも必要です
ブロックしますが、Massifはこれを説明できません。

--stacks = [ディフォルト： 番号]
スタックプロファイリングを実行するかどうかを指定します。 このオプションはMassifを遅くします
大幅に、デフォルトでオフになっています。 Massifは、メインスタックに
起動時のサイズはゼロです。 これは真実ではありませんが、そうでなければ正確に行うことは困難です。
さらに、ゼロから開始すると、メインスタックの一部のサイズがわかりやすくなります。
ユーザープログラムが実際に制御できること。

--pages-as-heap = [ディフォルト： 番号]
mallocされたブロックではなく、ページレベルでメモリをプロファイリングするようにMassifに指示します
レベル。 詳細については、上記を参照してください。

--depth = [ディフォルト： 30]
詳細なスナップショットのために記録された割り当てツリーの最大深度。 それを増やす
Massifの実行がやや遅くなり、より多くのメモリを使用し、より大きな出力を生成します
ファイル。

--alloc-fn =
このオプションで指定された関数は、ヒープであるかのように扱われます。
などの割り当て機能 malloc関数。 これは、ラッパーである関数に役立ちます
malloc関数 or NEW、割り当てツリーを興味のない情報で埋めることができます。
このオプションは、コマンドラインで複数回指定して、複数の名前を付けることができます
機能します。

名前付き関数は、それが
スタックトレース、またはこのように扱われる別の関数のすぐ下。 たとえば、
機能 malloc1 それはラップします malloc関数, malloc2 それはラップします malloc1、指定するだけ
--alloc-fn = malloc2 効果はありません。 指定する必要があります --alloc-fn = malloc1 as
良い。 これは少し不便ですが、その理由は割り当てをチェックするためです
関数は遅く、Massifが見通すのをやめることができれば、多くの時間を節約できます。
一致するものが見つかるとすぐに、トレースエントリをスタックする必要はありません。
すべてのエントリを続行します。

C ++名はデマングルされていることに注意してください。 オーバーロードされたC ++名を記述する必要があることにも注意してください
略さずに。 シェルがそれらを分割するのを防ぐために、一重引用符が必要になる場合があります。
具体的な例を挙げますと、以下の通りです。

--alloc-fn = 'operator new（unsigned、std :: nothrow_t const＆）'

--ignore-fn =
直接ヒープ割り当て（つまり、 malloc関数, NEW、など、または関数の呼び出し
によって名付けられた --alloc-fn オプション）このオプションで指定された関数で発生する
無視されます。 これは主にテスト目的で役立ちます。 このオプションを指定できます
複数の関数に名前を付けるために、コマンドラインで複数回。

任意 再割り当て 無視されたブロックの 再割り当て 呼び出しは行います
無視された関数では発生しません。 これにより、ヒープサイズが負になる可能性が回避されます
無視されたブロックが縮小された場合 再割り当て.

C ++関数名の記述規則は、 --alloc-fn 上記。

--threshold = [ディフォルト： 1.0]
合計メモリサイズのパーセンテージとしての、ヒープ割り当ての有意性しきい値。
これより少ないアカウントの割り当てツリーエントリが集約されます。 ご了承ください
これは、同じ名前のms_printのオプションと並行して指定する必要があります。

--peak-inaccuracy = [ディフォルト： 1.0]
Massifは、必ずしも実際のグローバルメモリ割り当てのピークを記録するわけではありません。 沿って
デフォルトでは、グローバルメモリ割り当てサイズが
少なくとも1.0％前のピーク。 これは、多くのローカル割り当てが存在する可能性があるためです
途中でピークに達し、すべての人に対して詳細なスナップショットを作成するのはコストがかかります
XNUMXつを除いてすべてが後で破棄されるため、無駄になります。 この不正確さは
このオプションを使用して（0.0％にさえ）変更されましたが、Massifの実行速度は大幅に遅くなります。
数がゼロに近づきます。

--time-unit = [ディフォルト： i]
プロファイリングに使用される時間単位。 XNUMXつの可能性があります：指示
実行された（i）、これはほとんどの場合に適しています。 実際の（ウォールクロック）時間（ms、つまり
ミリ秒）、これは時々便利です。 ヒープに割り当て/割り当て解除されたバイト
および/またはスタック（B）。これは非常に短期間のプログラムやテストに役立ちます。
目的は、さまざまなマシン間で最も再現性が高いためです。

--detailed-freq = [ディフォルト： 10]
詳細なスナップショットの頻度。 と --detailed-freq = 1、すべてのスナップショットが詳細に表示されます。

--max-snapshots = [ディフォルト： 100]
記録されたスナップショットの最大数。 Nに設定すると、非常に例外的なすべてのプログラムで
短期間のスナップショットの場合、スナップショットの最終的な数はN / 2からNの間になります。

--massif-out-file = [ディフォルト： massif.out。％p]
プロファイルデータをデフォルトの出力ファイルではなくファイルに書き込みます。
massif.out。 。 The %p 　 %q フォーマット指定子を使用して、プロセスIDを埋め込むことができます
および/または名前の環境変数の内容（
コアオプション -ログファイル.

SGチェック OPTIONS

現在、SGCheck固有のコマンドラインオプションはありません。

BBV OPTIONS

--bb-out-file = [ディフォルト： bb.out。％p]
このオプションは、基本ブロックベクターファイルの名前を選択します。 The %p 　 %q 形式でアーカイブしたプロジェクトを保存します．
指定子を使用して、プロセスIDや環境のコンテンツを埋め込むことができます
コアオプションの場合と同様に、名前の変数 -ログファイル.

--pc-out-file = [ディフォルト： pc.out。％p]
このオプションは、PCファイルの名前を選択します。 このファイルはプログラムカウンターアドレスを保持します
さまざまな基本ブロックの関数名情報。 これは組み合わせて使用​​できます
基本ブロックベクターファイルを使用して、関数名だけでなく関数名を使用して早送りします
命令カウント。 The %p 　 %q フォーマット指定子を使用して、プロセスを埋め込むことができます
IDおよび/または名前の環境変数の内容（
コアオプション -ログファイル.

--interval-size = [ディフォルト： 100000000]
このオプションは、使用する間隔のサイズを選択します。 デフォルトは100億です
一般的に使用される値である命令。 他のサイズを使用できます。 小さい
間隔は、よりきめ細かいフェーズのプログラムに役立ちます。 ただし、間隔サイズは小さい
ウォームアップ効果により精度の問題が発生する可能性があります（さまざまなものを早送りする場合
アーキテクチャの機能は初期化されておらず、いくつかの時間がかかります
完全なシミュレーションがない状態に「ウォームアップ」する前の命令
早送り。 間隔のサイズが大きいと、これが軽減される傾向があります。）

--instr-count-only [ディフォルト： 番号]
このオプションは、命令カウントの合計のみを表示し、表示しないようにツールに指示します
実際の基本ブロックベクトルファイルを生成します。 これは、デバッグや
大きな基本ブロックベクトルを生成せずに命令カウント情報を収集する
ファイル。

ラッキー OPTIONS

--basic-counts = [ディフォルト： はい]
有効にすると、Lackeyは次の統計と情報を出力します。
クライアントプログラムの実行：

1.によって指定された関数への呼び出しの数 --fnname オプション（デフォルト
メインです）。 プログラムのシンボルが削除されている場合、カウントは常に
ゼロ。

2.検出された条件付きブランチの数、および
取られたもの。

3.プログラムによって入力および完了されたスーパーブロックの数。 のために注意してください
JITによって行われる最適化では、これはまったく正確な値ではありません。

4.ゲスト（x86、amd64、ppcなど）の命令とIRステートメントの数
実行されました。 IRは、ValgrindのRISCのような中間表現であり、
計装が行われます。

5.これらのカウントのいくつかの間の比率。

6.クライアントプログラムの終了コード。

--detailed-counts = [ディフォルト： 番号]
有効にすると、Lackeyは、ロード、ストア、およびALUのカウントを含むテーブルを出力します
IRタイプによって区別される操作。 IRタイプは、IRによって識別されます
名前（「I1」、「I8」、...「I128」、「F32」、「F64」、および「V128」）。

--trace-mem = [ディフォルト： 番号]
有効にすると、Lackeyはによって行われたほぼすべてのメモリアクセスのサイズとアドレスを出力します
プログラム。 詳細については、ファイルlackey /lk_main.cの上部にあるコメントを参照してください。
出力フォーマット、それがどのように機能するか、およびアドレストレースの不正確さについて。 ノート
このオプションは膨大な量の出力を生成します。

--trace-superblocks = [ディフォルト： 番号]
有効にすると、Lackeyはすべてのスーパーブロックのアドレスを出力します（単一のエントリ、
プログラムによって実行される複数の出口、コードの線形チャンク）。 これは主に
Valgrind開発者への関心。 ファイルの上部にあるコメントを参照してください
出力形式の詳細については、lackey /lk_main.cを参照してください。 このオプションは生成することに注意してください
大量の出力。

--fnname = [ディフォルト： 主要]
呼び出しがカウントされる関数を変更します --basic-counts = yes 指定されています。

onworks.net サービスを使用してオンラインで valgrind.bin を使用する