使用 Lauterbach Trace 查看函数运行时图答案

【问题标题】：Viewing graphs of function runtimes with Lauterbach Trace使用 Lauterbach Trace 查看函数运行时图
【发布时间】：2019-03-26 17:38:32
【问题描述】：

我正在调试一个长时间运行的方法在死亡前被频繁调用的崩溃。我主要担心的是难以确定嵌套和/或递归调用的位置。

Trace->Chart->Symbols 窗口显示了在给定时间运行的函数的图形，对于以下调用，该图形如下所示：

         display
            |
       drawChildren
       /         \
  drawTitle   drawImage
      |           |
   display     display
      |           |
drawChildren  drawChildren

display      | _     _   _       _   _     _
drawChildren |  |_  | |_| |  _  | |_| |  _|
drawTitle    |    |_|     |_| | |     | |
drawImage    |                |_|     |_|

我想要的是更类似于火焰图的东西，其中每个调用的持续时间一目了然，嵌套调用更容易发现：

display______________________________
 drawChildren_______________________
  drawTitle_______ drawImage_______
   display_______   display_______
    drawChildren     drawChildren

我尝试查看列表视图，但发现在有问题的代码中导航调用和迭代的数量很麻烦。我知道可以对图表视图进行排序，但是有什么方法可以让数据得到不同的视图？

【问题讨论】：

标签： trace32 lauterbach

【解决方案1】：

我猜最符合您需求的命令是

Trace.Chart.Nesting
Trace.ListNesting

您不会在菜单中找到此命令。您必须在 TRACE32 应用程序窗口底部的命令行中输入它们（B:: 后面）或使用命令行下方的软键按钮来查找这些命令。

请注意，您可以使用“/Track”选项使跟踪窗口彼此同步。

【讨论】：

Trace.Chart.Nesting 看起来很有希望，尽管在它尝试处理后不久我看到“堆栈溢出”。 Trace.Chart 还在工作，所以我想我必须先弄清楚才能使用它
Trace.Chart.Nesting 使用所谓的“嵌套分析”，而 Trace.Chart（又名Trace.Chart.sYmbol）使用所谓的“平面分析”。 “平面分析”基本上只是分析程序计数器，而“嵌套分析”实际上是分析函数的入口和出口，要复杂得多。如果函数入口数与函数出口数不匹配，则会出现“STACK OVERFLOW”。
如果您在目标上使用操作系统，则必须通过命令TASK.CONFIG（或在 AutoSar 的情况下为 TAKS.ORTI）加载操作系统感知以使用“嵌套分析”。此外，您必须跟踪活动任务。这可以通过数据跟踪 (Break.Set TASK.CONFIG(magic) /Write /TraceData) 或 - 在没有数据跟踪的 ARM CPU 上 - 通过在每个任务切换上写入 Context-ID 寄存器并通过 ETM.ContextID 启用 Context-ID 跟踪来实现。
对于运行 ChibiOS 的 ARM Cortex M3，我无法使其可靠地工作，但是当我获得输出时，它非常有用。我怀疑这可能与函数进入/退出计数有关
对于 ARM Cortex M3 和 ChibiOS 加载（在您的 ELF 文件之后）使用TASK.CONFIG ~~/demo/arm/chibios/chibios.t32 的操作系统感知，使用ITM.DataTrace CorrelatedData 通过 ITM 启用数据跟踪，最后请求数据样本以更改活动Break.Set TASK.CONFIG(magic) /Write /TraceData 的任务。这应该会在 Trace.CHART.TASK 中为您提供任何新跟踪记录的结果，并允许嵌套时序分析。