我正在基于飞思卡尔MX51的主板
Linux 2.6.35上开发一个GUI重的C应用程序.我想执行堆分析.

不幸的是,我发现的所有堆分析工具要么过于侵入,要么表面上不能在ARM上工作.我试过的具体工具：

> Valgrind Massif：由于平台的CPU微弱,我的平台无法工作. Massif引入的80％CPU时间开销导致我的应用程序中的一系列问题无法得到补偿.
> gperftools(以前的Google Performance Tools)tcmalloc：除了堆分析器之外,这个相当非侵入性的,基于库的libc malloc()的所有功能都替换了我的目标.换句话说,线程缓存分配器可以工作,但分析器却没有.对于任何好奇的人,我将在下面解释探查器的故障模式.

任何人都可以建议一组替换工具在ARM平台上执行C堆分析吗？理想输出最终将是一个有向分配图,类似于gperftools的tcmalloc输出.资源利用率低是必须的 – 我的平台资源高度受限.

gperftools’tcmalloc的失败模式解释如下：

我只是为那些好奇的人提供这些信息;我不指望有回应.我在下面看到类似于gperftools问题#407的内容,除了ARM而不是x86.
具体来说,我总是收到消息“未找到Hooked allocator frame,返回空的跟踪”.我花了一些时间来调试这个问题,看起来,当动态链接tcmalloc库时,我的应用程序和动态库之间边界的帧指针为空 – 堆栈不能在调用动态库的“上方”走过.

gperftools问题#407：hxxp：//code.google.com/p/gperftools/issues/detail？id = 407

stackoverflow用户在ARM上看到类似的问题：Missing frames on shared libraries on ARM

最佳答案 堆.有许多方法可以做到,但我只遇到了嵌入式土地中重要的3种主要类型：

>链接列表堆.每个alloc都在“used”列表中进行跟踪.一旦被释放,它们就会被放入“免费”列表中.在释放时,相邻的可用内存块被“连接”成更大的块. Allocs可以是任何尺寸.每个alloc和free都是一个O(N)op,因为它必须遍历空闲列表,为你提供一块内存,并将空闲块分解为接近你要求的大小,同时将剩余的块留在空闲列表中.由于每个alloc的开销增加,该系统本身不能在较小的系统上使用.如果不采取措施将其最小化,这也会导致内存碎片.
>固定尺寸​​(单位)堆.你将堆分成相同大小(较小)的部分.这会浪费内存,具体取决于块的大小(以及您创建的块大小,固定分配器堆的数量),但alloc和free都是O(1)时间操作.没有搜索,没有加入.这种风格通常与第一个用于“小对象分配”的风格相结合,因为我使用的引擎有95％的分配低于设定大小(比如256字节).这样,您可以将单元堆用于小型分配,以获得极高的速度和最小的内存丢失,同时将列表堆用于较大的分配.也没有外部碎片的记忆.
>可重定位的内存堆.你没有给出内存指针,但处理.这样,在幕后,您可以在需要时更改内存指针以删除碎片或其他内容.高开销. @ $$商的高度痛苦,因为它很容易被滥用并且全部悬挂指针.还为每个内存解除引用添加了开销.但是想提一下.

有一些基本模式.您可以在野外找到使用它们的各种库,还有内置的分配数量,碎片和其他有用的统计数据.虽然我不建议将其用于满足好奇心之外的任何事情,因为没有工作的malloc的调试确实很痛苦.添加线程支持也非常简单,但同样,下载现成的解决方案是更好的选择.

以上信息适用于所有平台,ARM或其他,虽然我的大部分经验都是基于ARM的低级别的东西,所以以上信息是针对您的平台进行的战斗测试.希望这可以帮助！