0

ここにリンクの説明を入力

こんにちは、Kcachegrind を使用して C コードをプロファイリングしています。しかし、コール グラフの出力ツリー マップ ビューと混同しています (上記のリンクを参照)。コードをコンパイルしました: valgrind --tool=callgraph ./Program_name と kcachegrind callgrind.out.8389。次の質問があります。

  1. main() 関数の上に、「main() の下」と 0x08048bb0 関数が表示されます。これらは何ですか？コンパイラ/OS がプログラム イメージをロードせず、直接 main() にジャンプするためでしょうか。main() を呼び出す前に、プロセスが大量のコードを実行して「実行のためのスペースを空ける」ことを読んだことがあります。これが理由ですか？

  2. ツリーの下部には、名前の代わりに 16 進数の関数が多数表示されます。どうしてこれなの？

  3. これらの 16 進数は、これらの関数のコード セクションの絶対アドレス (つまり、オフセットではない) または仮想アドレス (またはシンボル) ですか? か否か？

  4. -g オプションを使用して、Ubuntu 10.10 でプログラムをコンパイルしました。これらの 16 進数は、「デバッグ情報」がないことと関係がありますか?

  5. 「nm program_name」を使用して、何が起こっているのかを把握しようとしましたか? 上記のコール グラフの場合、次の出力が得られます。

root@xTR:/home/ahuq/system/client/xTR# nm UDPClientProject 
0804af14 d _DYNAMIC
0804aff4 d _GLOBAL_OFFSET_TABLE_
08049b4c R _IO_stdin_used
         w _Jv_RegisterClasses
0804af04 d __CTOR_END__
0804af00 d __CTOR_LIST__
0804af0c D __DTOR_END__
0804af08 d __DTOR_LIST__
08049ebc r __FRAME_END__
0804af10 d __JCR_END__
0804af10 d __JCR_LIST__
0804b0a0 A __bss_start
         U __cxa_atexit@@GLIBC_2.1.3
0804b098 D __data_start
08049b00 t __do_global_ctors_aux
08048c30 t __do_global_dtors_aux
0804b09c d __dso_handle
08048be0 T __gmon_start__
08049aba T __i686.get_pc_thunk.bx
0804af00 d __init_array_end
0804af00 d __init_array_start
08049a50 T __libc_csu_fini
08049a60 T __libc_csu_init
         U __libc_start_main@@GLIBC_2.0
         U __monstartup@@GLIBC_2.0
         U __stack_chk_fail@@GLIBC_2.4
0804b0a0 A _edata
0804b0c4 A _end
08049b2c T _fini
08049b48 R _fp_hw
0804890c T _init
         U _mcleanup@@GLIBC_2.0
08048bb0 T _start
080490aa T access_file_insert_data
         U alarm@@GLIBC_2.0
0804922d T append
08049ac0 T atexit
         U bzero@@GLIBC_2.0
0804b0a4 b called.3477
         U calloc@@GLIBC_2.0
         U ceil@@GLIBC_2.0
08049517 T client_timeout_signal_handle
0804b0a8 b completed.7065
0804b098 W data_start
080496e5 T delete_query
080494cc T display
0804b0ac b dtor_idx.7067
0804b0b4 B err
08049658 T err_message
08049b48 A etext
         U exit@@GLIBC_2.0
         U fclose@@GLIBC_2.1
         U fgets@@GLIBC_2.0
         U fopen@@GLIBC_2.1
         U fprintf@@GLIBC_2.0
08048c90 t frame_dummy
0804953a T get_map_notify_packet
         U htons@@GLIBC_2.0
         U inet_pton@@GLIBC_2.0
08049733 T insert_query
08048cb4 T main
         U malloc@@GLIBC_2.0
080495c6 T map_notify_packet_initialization
08048f3c T map_register_packet_initialization
         U mcount@@GLIBC_2.0
         U memcpy@@GLIBC_2.0
         U memset@@GLIBC_2.0
         U mysql_close@@libmysqlclient_16
         U mysql_errno@@libmysqlclient_16
         U mysql_error@@libmysqlclient_16
         U mysql_init@@libmysqlclient_16
         U mysql_query@@libmysqlclient_16
         U mysql_real_connect@@libmysqlclient_16
         U mysql_sqlstate@@libmysqlclient_16
0804b0c0 B num_of_mapping
         U perror@@GLIBC_2.0
0804b0b0 B position
         U printf@@GLIBC_2.0
         U puts@@GLIBC_2.0
         U recvfrom@@GLIBC_2.0
         U sendto@@GLIBC_2.0
         U signal@@GLIBC_2.0
         U socket@@GLIBC_2.0
0804b0a0 B stderr@@GLIBC_2.0
         U strcat@@GLIBC_2.0
         U strcpy@@GLIBC_2.0
         U strlen@@GLIBC_2.0
         U strtok@@GLIBC_2.0
08049781 T tcp_server_access_main
0804b0b8 B udp_cli_program_cycle
0804b0bc B xx1
  1. 「nm」出力に存在するコール グラフからの 16 進アドレスが表示されません。私は混乱しています。

私を助けてください。

さよなら。

4

1 に答える 1

1

main の上のノードは、main を呼び出してそこから戻るコードに対応します。これは、グローバルを初期化し、クリーンアップするコードです。

名前の代わりに 16 進数の関数は、デバッグ情報またはスタック情報が利用できなかった場所に対応します。お気づきのように、それらは通常、ライブラリ内またはライブラリ間にあります。アドレスは絶対仮想アドレスです。それらは、デバッグ情報を持たない動的に読み込まれたライブラリにあるか、再配置されたか、またはデバッグ シンボルを使用してコンパイルされていないプログラムの一部にあるため (.静的ライブラリ)。そんなに簡単に見つけられたら、自動的に見つけられたでしょう。

いずれにせよ、消費量全体の約 12% しか占めていません。それらは SQL コードと XML コードの間にあります。

于 2011-11-09T11:17:41.200 に答える