ARM Cortex-M3用gcc工具链开发如何进行性能分析？
本帖最后由 hugeice 于 2012-9-17 18:29 编辑请问用GNU工具链做ARM Cortex-M3开发的同学们：如何对软件进行性能分析？
我知道GNU有自己的性能分析方案：gprof。不过我在CodeSourcery的Sourcery CodeBench Lite ARM EABI的Getting Started文档中看到如下一段：
Profiling is enabled by means of the -pg compiler option. In this mode, the compiler inserts a call
to __gnu_mcount_nc into every function prologue. However, no implementation of __gnu_
mcount_nc is provided (to do so would be impossible without knowledge of the execution envir-
onment).
也就是说需要自己实现__gnu_mcount_nc来统计？那有没有针对Cortex-M3裸奔的__gnu_mcount_nc实现呢？
我查看了Sourcery CodeBench Lite的安装目录，没有发现类似libporf之类的库。
请用过的同学说说：如何对Cortex-M3下的裸奔代码进行Profiling? 用GCC做单片机开发的同学，说说你们是怎么做性能分析的吧？ 跑coremark。。。。 jisaowang 发表于 2012-9-18 15:37 static/image/common/back.gif
跑coremark。。。。
CoreMark是跑分软件吧，我不是要对单片机进行性能分析，而是要对我自己写的程序进行性能分析，coremark有何用？ hugeice 发表于 2012-9-18 18:44 static/image/common/back.gif
CoreMark是跑分软件吧，我不是要对单片机进行性能分析，而是要对我自己写的程序进行性能分析，coremark有 ...
评测编译器效能。。。。。 jisaowang 发表于 2012-9-18 20:26 static/image/common/back.gif
评测编译器效能。。。。。
CoreMark应该不是评测编译器效能吧，应该是评测芯片效能的。类似PC上的BenchMark之类的软件。
可能我没有说清楚，我需要对我自己的程序进行性能分析，找出程序中的性能瓶颈，再对其进行优化，以提高整个程序的性能。
因此我需要类似gprof/oprof/sysprof之类的软件，但是oprof和sysprof都是linux系统下的，而grpof在arm-eabi上提供的方案不完整（只提供了向所有C语言函数序言（prologue）部分插入__gnu_mcount_nc调用的代码，但却并没有提供该函数的实现）。
我正在学习gprof的原理，原来GNU的方案是用一个定时器对PC（程序计数器）进行采样，然后统计PC落在各个函数中的频率来计算函数的执行时间，OMG！这样有操作系统比较容易（在任务调度的定时器中采样），对于没有操作系统裸奔来说只能自己用定时采样了！不过我觉得这样采样的结果准确吗？？毕竟PC的更新速度是非常快的，两次采样之间PC可能已经经过很多函数了！
而GCC插入每个C函数序言部分的那个对__gnu_mcount_nc的调用只是用来获取函数调用次数（而不是函数执行时间）以及函数调用关系的。
systick 看当前的PC，LR，结合elf文件分析。瞎说的。 以前试着用GCC编过一个现实程序，同样的程序用keil在编译一次，发现程序执行速度存在很大差别，GCC的运行速度慢，很奇怪。串行通讯可以正常使用，应该可以说明系统时钟初始化是正常的。 bitter 发表于 2012-9-19 12:38 static/image/common/back.gif
systick 看当前的PC，LR，结合elf文件分析。瞎说的。
GNU的方案应该就是这样的，只要按照gprof的格式要求生成那个gmon.out文件，然后用gprof打开就可以看到函数执行时间、次数、调用关系等。
不过感觉还是在函数调用前后插入计时代码比较简单准确，gprof不这样做的原因是在分时多任务操作系统下，采样函数开始和结束时的时间来计算函数执行时间是不准确的，任务调度可能会导致函数所在的任务被挂起，从而测不到函数实际在CPU上执行的时间。因此只能采用这种定时采样统计的近似方法。 xjj123456789 发表于 2012-9-19 12:52 static/image/common/back.gif
以前试着用GCC编过一个现实程序，同样的程序用keil在编译一次，发现程序执行速度存在很大差别，GCC的运行速 ...
我的EK-LM3S8962开发板的例程中Makefile文件中是没有开速度优化，而是开的代码尺寸优化的“-Os”，你测试gcc编译的程序慢可能是这个原因吧。
hugeice 发表于 2012-9-19 09:51 static/image/common/back.gif
CoreMark应该不是评测编译器效能吧，应该是评测芯片效能的。类似PC上的BenchMark之类的软件。
可能我没 ...
不能么，我看各家编译器比拼同一硬件平台的cormark分数比的不亦悦乎啊，人家现在不光评测芯片效能，对同一芯片一样评测编译器效能呢~ jisaowang 发表于 2012-9-19 15:22 static/image/common/back.gif
不能么，我看各家编译器比拼同一硬件平台的cormark分数比的不亦悦乎啊，人家现在不光评测芯片效能，对同 ...
我是要评测我自己程序各个部分（函数）的性能，并不是要评测芯片或者编译器的性能！ 终于搞出来了：time:
-------------------------------------------------------------------------
symbol count time self time percent
-------------------------------------------------------------------------
.text.client_packet_send 66030 2280567910 2255322625 27.14
udp_unlock_tx_buf 61369 1479935452 1394282248 16.78
ip_unlock_tx_buf 61369 889198191 803570944 9.67
.text.transmit 122740 595292159 524482919 6.31
eth_isr 122299 430730744 430730744 5.18
udp_lock_next_tx_buf 70038 271922728 271922728 3.27
fcc_input 54355 224735431 224735431 2.70
fcc_fill_send_data_test 61315 199370037 199370037 2.40
.text.queue_lock_head 335689 203146426 159392146 1.92
udp_unlock_rx_buf 54356 158484737 158484737 1.91
.text.on_data_ack 54301 155454583 155454583 1.87
.text.receive 60930 153082801 153082801 1.84
.text.queue_lock_tail 253710 179582968 146689655 1.77
eth_lock_next_tx_buf 192777 271966558 135048067 1.63
fcc_clock 90242 2413744365 133176455 1.60
eth_unlock_tx_buf 61370 573585099 112736876 1.36
.text.udp_checksum 115728 100635484 100635484 1.21
ip_lock_next_tx_buf 70038 218296754 100083815 1.20
dhcp_clock 90242 114253858 99224714 1.19
udp_lock_next_rx_buf 90243 353649377 85276693 1.03
ip_lock_next_rx_buf 90245 211583407 85047970 1.02
ip_clock 90242 203972712 77239101 0.93
.text.queue_unlock_head 115745 87985182 73625391 0.89
.text.queue_unlock_tail 115748 83395770 68579999 0.83
.text.queue_is_empty 451434 58114071 58114071 0.70
eth_lock_next_rx_buf 90262 113089143 51591812 0.62
.text.queue_is_full 369458 47709084 47709084 0.57
ip_unlock_rx_buf 54358 116915818 41361909 0.50
.text.udp_datagram_check 54359 56777903 38219855 0.46
eth_unlock_rx_buf 54375 75577448 34215567 0.41
ip_check_sum 115729 27828190 27828190 0.33
arp_clock 90242 12479753 12462145 0.15
arp_query 70036 10097673 10097673 0.12
eth_get_mac_addr 61372 9021684 9021684 0.11
.text.rtt_adjust 47393 7641382 7641382 0.09
eth_get_status 59234 7344506 7344506 0.09
.text.sm_on_bound 55062 7106700 7106700 0.09
arp_request 8669 7430554 6329373 0.08
udp_send 54 1318585 1318585 0.02
.text.arp_send 8669 1100963 1099568 0.01
.text.sm_on_init 1974 282089 251253 0.00
jrand 1568 203330 203330 0.00
.text.sm_on_selecting 489 106697 72814 0.00
UARTprintf 1 30779 30779 0.00
UARTwrite 1 30117 30117 0.00
arp_input 16 16306 10751 0.00
.text.start_msg 2 8954 8954 0.00
.text.add_client 54 8412 8412 0.00
dhcp_input 2 7076 5864 0.00
.text.arp_update 17 5773 5773 0.00
.text.build_request 1 9129 3991 0.00
eth_read_hw_status 1 3293 3293 0.00
eth_init 1 2620 2620 0.00
ip_set_local_addr 1 2471 2164 0.00
.text.build_opt 10 1688 1688 0.00
.text.build_discover 1 6315 1577 0.00
.text.sm_on_requesting 2 3820 1349 0.00
.text.parse_options 6 1212 1212 0.00
ip_init 1 3758 995 0.00
ip_configure 1 1222 786 0.00
.text.end_msg 2 582 582 0.00
UARTStdioInit 1 441 441 0.00
arp_set_local_address 2 318 318 0.00
eth_set_mac_addr 1 151 151 0.00
arp_init 1 143 143 0.00
fcc_init 1 135 135 0.00
arp_set_max_age 1 127 127 0.00
.text.delay 1 126 126 0.00
dhcp_init 1 126 126 0.00
-------------------------------------------------------------------------
用GCC的函数跟踪功能，统计每个函数的执行时间，然后用perl分析.map文件得到函数名。
有空的话我可以写一个实现说明（下位机程序只需要增加一个文件，修改Makefile，修改几个中断处理函数的原型，另外，提供一个用于计时的get_cycle函数）。 其实可以得到函数调用关系，不过没用精力搞了，这个先用着。
页:
[1]