Linuxの「perf record」をlibcおよびlibstdc ++シンボルに対して機能させる方法は？

12

私が使用しているperf record -gプログラムをプロファイルするのx86-64 Linux上で。libcまたはlibstdc ++のいくつかのシンボルは0、親として：__GI___strcmp_ssse3（libc）およびstrcmp@plt（libstdc ++）などです。（デバッガでこれらのシンボルを実際にブレークして、バックトレースを取得できます。）

これらの関数の主要な呼び出し元と、それらが記録されない理由を知りたいです。これは、libcとlibstdc ++にx86_64のフレームポインターがないためですか？そして、実際には、これを回避する方法はありますか？

glibc profiling perf

— ベンジャミン・レデリングス
ソース

5

これは古い質問ですが、これはで可能になりました--call-graph dwarf。manページから：

 -g
       Enables call-graph (stack chain/backtrace) recording.

   --call-graph
       Setup and enable call-graph (stack chain/backtrace) recording, implies -g.

           Allows specifying "fp" (frame pointer) or "dwarf"
           (DWARF's CFI - Call Frame Information) as the method to collect
           the information used to show the call graphs.

           In some systems, where binaries are build with gcc
           --fomit-frame-pointer, using the "fp" method will produce bogus
           call graphs, using "dwarf", if available (perf tools linked to
           the libunwind library) should be used instead.

これにはやや最近のLinuxカーネルが必要だと思います（> = 3.9？完全にはわかりません）。ディストリビューションのperfパッケージがlibdwまたはlibunwindとリンクされているかどうかを確認できますreadelf -d $(which perf) | grep -e libdw -e libunwind。Fedora 20では、perfはlibdwにリンクされています。

— ajduff574
ソース

perf record --call-graph dwarf私のためにこの問題を解決します。残念ながら、ドワーフ情報を使用する場合、perfには呼び出し元ベース（つまり「反転」）のコールグラフを表示する際に問題があるようです。だからこそ、視覚化のためにFlameGraphを使い始めました。

— 青

ドワーフの巻き戻しを使用すると、プロファイリング中に非常に大きなオーバーヘッドが発生することに注意してください

— Azsgy

-2

perfシステムコールの経過時間を表示するカーネルツールです。GNU gprofを探しています。「gprof-コールグラフプロファイルデータの表示」。gprofを使用するには、ソースを-pgスイッチでコンパイルする必要があります。

これに加えて、などの洗練されたプロファイリングツールがたくさんありますeclipse-cdt-profiling-framework。