問題タブ [call-graph]

スタック内の深さに応じてインデントされた関数が呼び出されたときに、gdb が対象の関数を出力するようにするにはどうすればよいですか?

私は（でっち上げ）のようなことを言えるようになりたい：

そして、呼び出されたときに Foo または Bar で始まるすべての関数を gdb に出力させます。gnu cflow のようなものですが、デバッグ シンボルを使用し、実際に呼び出される関数のみを表示することを除いて、可能なすべての呼び出しフローではありません。

役に立たないツールには、関数が最も頻繁に呼び出された結果を並べ替える cachegrind、callgrind、および oprofile が含まれます。呼び出す順序を保持する必要があります。

多くの Foo および Bar 関数があるため、ワイルドカード (または同等のもの) は不可欠です。私は絶対にすべての機能を記録することに落ち着きますが. または、特定のライブラリにすべての関数を記録するように gdb に指示することもできます。

一部の GDB ウィザードには、この一般的なジョブのスクリプトが必要です!

動的コール グラフを視覚化するためのツールはありますか? Visual Basic 6 用の参照を見ましたが、.NET 用が欲しいです。

自分でビジュアライザーを作成する必要がある場合、.NET プロファイリング APIを使用する必要がありますか、それとも Mono.Cecilで何かを行う必要がありますか? Cecil を使用して CLI ランタイムの作成を開始しましたが、事前に実行ルートがわからず、すべてをインストルメント化する必要があるため、コールグラフ記録呼び出しをアセンブリに挿入した方が簡単だと思います。

GUIからC計算コードを分割するためにリファクタリングしているレガシーCコードのコレクションがあります。これは、K&R スタイルの宣言である非常に再帰的な数学的コア コードによって複雑になります。関数パラメーターのネストされた使用のために、これらをANSI宣言に変換する試みをすでに放棄しました（最後の4つのコンパイラエラーを取得できませんでした）。

いくつかのファイルを純粋な DLL に移動し、公開する最小限のインターフェイスを決定する必要があります。これには、型付きインターフェイスを公開するためのラッパー関数の書き込みが必要になります。

重要なソース ファイルを Doxygen @callergraph マークアップでマークアップしたので、個々の関数について有益なグラフが生成されます。それを超えてやりたいことは、これらのグラフを統合して、外の世界に公開される関数の最も狭い境界を決定できるようにすることです。

元のヘッダー ファイルは役に立ちません。すべてが型指定されていない C 関数として公開されます。

何百もの関数があるため、生成されたコーラーグラフを簡単に検査するのは大変です。

ある種の DOT マージ ツールを作成することを検討しています。

これがグラフィカルなソリューションであることに執着しているわけではありません。誰かが別の分析ツール (無料または比較的安価) または Doxygen の XML 出力を使用して同じ目標を達成する手法を提案できれば、非常に嬉しく思います。

ファイル レベルで融合された callergraph は、単純なリストよりもクライアントのドキュメントに一定の魅力があります :-)

Cコードのソースファイルがたくさんある大きなワークスペースがあります。オブジェクトブラウザを使用してMSVS2005の関数から呼び出された関数を確認できますが、MSVC 6.0でも、特定の関数から呼び出された関数のみが非グラフィカルな種類の表示で表示されます。main()さらに、たとえば、から開始して呼び出される関数、次にそれから呼び出される関数など、リーフレベル関数の奥深くには表示されません。

関数を使って絵で関数呼び出しグラフを作成し、矢印などcalleeで接続して、関数の最後のレベルから開始するか、少なくとも1つのCソースファイル内のすべての関数の呼び出しグラフを絵で表示するツールが必要です。このグラフを印刷できたらいいなと思います。callermain()

それを行うための良いツールはありますか（無料のツールである必要はありません）？

Cファイルが与えられた場合、gccは、発生したすべての関数呼び出しのリストを、呼び出し自体と関数の宣言の両方のファイル名と行番号とともに吐き出すことができますか?

gcc は -g を使用してこの情報を何らかの形で保持し (デバッガーはそれに依存します)、-dr を使用して制御フロー グラフをダンプできることを知っています (ただし、ファイル名や行番号はありません)。しかし、gcc 出力を受け取り、私が望むことを行うすぐに使用できるツールはありますか?

そのようなツールで gcc を使用したい理由は、ツールが独自のプリプロセッサに依存している場合でも、ほとんどの gcc ベースのソフトウェアに付属している標準のビルド システム (./configure && make など) で使用できるようにするためです。および/またはパーサーは、適合するのが非常に面倒です。私はすでに、ctags などのいくつかのそのようなツールを認識しています。したがって、この質問は質問 525899のフォローアップです。

アイデアは、プログラムに特定の入力が与えられると、どういうわけか自動的に完全なプログラムにステップインし、その制御フローを、クラスとその変数のように使用されているすべてのデータと共にダンプしたいということです。これを行う簡単な方法はありますか？または、これは gdb を介したスクリプトによって実行できますか、または gdb で変更する必要がありますか?

この質問の理由は、デバッグ ツールに関するアイデアのためです。それがすることはこれです。プログラムに 2 つの異なる入力が与えられた場合、1 つは正しくない出力を引き起こし、もう 1 つは正しい出力を引き起こした場合、制御フローのどの部分が異なるかがわかります。

したがって、必要になると思うのは、差分エンジンに入るこれら 2 つの制御フローの完全なダンプです。そして、2 つの入力が同様の制御フローに従っている場合、(多くの場合) それらの diff は、バグが存在する理由についての良いアイデアを提供します。

これは、その上に構築された多くの機能を備えた非常に魅力的なツールにすることができます。

私はしばらくの間、プログラムの制御フローをトレースする GDB の進行を自動化する方法を見つけようと試みてきました。

コマンドを自動化する簡単な方法でも、nルーチンが呼び出される順序を確認できます。

n xx が GDB のステップ スルー回数である場合、問題が発生する可能性があることは認識していますが、問題は、コマンドは表示されますが、ルーチンのアドレスは表示されないことです! ただしn、GDB で手動で押すと (次に Return キーを押して前のコマンドを発行すると)、アドレスが表示されます。

GDBで次のことを試しました：

GDBは言い<breakpoint 1 at 0x123456>ます。私はタイプする：

しかし、期待どおりにループせず、アドレスの場所も表示されません :-(.

どんな助けでも大歓迎です！確かに、ルーチンが呼び出された順序を自動的に記録するのは簡単に違いありません??

（ほとんど文書化されていない）C＃コードの山が山積みになっているので、飛び込んでリファクタリングを開始する前に、その構造を視覚化したいと思います。私は過去に（他の言語で）コールグラフを生成するツールを使ってこれを行いました。

C＃での構造の発見を容易にするための優れたツールをお勧めしますか？

アップデート

私が（チューブを通して）ここで言及したツールに加えて、人々は.NETReflectorとCLRProfilerがこの機能を持っていると言います。これらの経験はありますか？

私はDependency Injection の原則を実行しようとしていますが、そうするのに苦労しています。

定期的にデータベースにアクセスして製品のリストを取得し、それらの製品に対して一連のテストを実行して安全性を判断する機能があります。

1 つまたは複数の製品が安全でないことが判明した場合は、ProductRecallオブジェクトをインスタンス化してディスパッチすることにより、リコールを発行する必要があります。

関数は次のようになります: (疑似コード)

ProductRecall問題は、コールグラフの真ん中にあるオブジェクトを「新規」にしていることです。これは、依存性注入の原則に違反しています。書かれているように、オブジェクトCheckProductSaftey()も作成しないとテストできません。ProductRecall

ただし、安全でない製品のリストを決定するのはオブジェクトであるため、オブジェクトProductRecallをオブジェクトに渡すことはできません。SafetyInspectorSafetyInspector

私はすべてにコンストラクター注入を使用しており、引き続き使用したいと考えています。ProductRecallsまた、いつでも複数発行する可能性があるため、単一のProductRecallオブジェクトをSafetyInspectorat 構造に渡すことは必ずしもできないことに注意してください。

助言がありますか？ありがとう！

GNU gprof 2.15.94.0.2.2 を使用して、呼び出しサイクルが大きい C++ プログラムのプロファイリングを行います。gprof のドキュメントに示されているように、コール グラフの出力に次のようなものが表示されることを期待していました。

ただし、私の<cycle as a whole>エントリには発信者がリストされていません。それらはすべて次のようになります。

私のサイクルは非常に大きいので、サイクル内の個々の関数を介して呼び出し元を追跡するのは非常に困難です。

出力にサイクル呼び出し元が表示されない理由と、それらを表示させる方法を誰か教えてもらえますか?