0

在此处输入链接描述

嗨,我正在使用 Kcachegrind 分析我的 C 代码。但我对调用图的输出树图视图感到困惑(参见上面提到的链接)。我已经编译了代码:valgrind --tool=callgraph ./Program_name,然后是 kcachegrind callgrind.out.8389。我有以下问题:

  1. 在 main() 函数上方,您将看到“main() 下方”和 0x08048bb0 函数。这些是什么?是不是因为编译器/OS没有加载程序镜像直接跳转到main()。我读到过,在调用 main() 之前,一个进程会执行大量代码以“清理执行空间”。这是原因吗?

  2. 在树的下半部分,你还会看到很多使用十六进制数字而不是名称的函数。为什么是这样?

  3. 这些十六进制数字是这些函数代码段的绝对地址(即不是偏移)还是虚拟地址(或符号)?或不?

  4. 我已经使用 -g 选项在 Ubuntu 10.10 中编译了我的程序。这些十六进制数字与“调试信息”的缺失有关吗?

  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”输出中存在的调用图中的十六进制地址。我很困惑。

请帮我。

再见。

4

1 回答 1

1

main 上面的节点对应于调用 main 并从中返回的代码。这是初始化全局变量和清理的代码。

具有十六进制数字而不是名称的函数对应于调试信息或堆栈信息不可用的地方。如果您注意到,它们通常位于库内部或库之间。地址是绝对的虚拟地址。您不会在程序中找到它们,因为它们要么位于没有调试信息的动态加载库中,要么被重新定位,要么位于未使用调试符号编译的程序部分(例如来自静态库)。如果它们那么容易找到,它们就会自动为您找到。

无论如何,它们只占总消费量的 12% 左右。它们介于 SQL 代码和 XML 代码之间。

于 2011-11-09T11:17:41.200 回答