Question

enter link description here

您好，我正在用Kcachegrind分析我的C代码。但我对调用图的输出树图视图感到困惑（参见上面提到的链接）。我编译了代码：valgrind --tool = callgraph ./Program_name然后是kcachegrind callgrind.out.8389。我有以下问题：

在main（）函数上方，你会看到“下面的main（）”和0x08048bb0函数。这些是什么？是因为编译器/ OS不加载程序映像并直接跳转到main（）。我已经读过，在调用main（）之前，进程执行大量代码以“清理执行空间”。这是什么原因？
在树的下半部分，你还会看到很多带有十六进制数字而不是名字的函数。这是为什么？
这些十六进制数是这些函数的代码部分的绝对地址（即不是偏移量）还是虚拟地址（或符号）？或不？
我使用-g选项在Ubuntu 10.10中编译了我的程序。这些十六进制数字是否与缺少“调试信息”有关？
我曾尝试使用“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

我没有看到“nm”输出中出现的调用图中的十六进制地址。我很困惑。

请帮帮我。

再见。

Answer 1

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

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

无论如何，他们只占消费总量的12％左右。它们位于SQL代码和XML代码之间。

令人困惑的Kcachegrind输出

1 个答案: