[参考译文] CODECOMPOSER：加载符号(DWARF 调试信息)突然花费更长的时间

Paul、 你能告诉我你正在使用的编译器和它的版本吗？  是否有可能私下共享示例输出文件？  我理解这是否可能。

你好 Andy。 非常感谢您能很快回复我。 我本来会更早跟进的,但我在压力下要释放出来。 这对我们来说非常重要、我们应该尽快结束这项工作。 我们将使用的编译器是 TI v20.2.1.LTS。 很遗憾、我无法分享输出文件。 如果我们可以召开团队会议、我或许可以共享我的屏幕、而且您可以告诉我需要查找什么内容。 或者、如果我能够为您提供输出文件、您会想要查找什么？ 我可以搜索哪些内容吗？ 下载符号时会发生什么情况？ 自上一篇文章以来、我甚至卸载并重新安装了 CCS、但这也未解决问题。  这种行为并非仅针对一个或两个输出文件、而是在我们的所有项目中发生。  我让我的一位同事运行同一个项目、他能够以正常的速度加载符号-大约35秒。 从计算机加载同一个项目时、加载符号需要4.5分钟。 因此、我的系统加载速度比以前慢约7倍(上星期五上午正常加载、 然后在晚些时候,它开始花7倍的时间-没有特别发生在之间,我可以回忆),而不是20正如我在开始提到。 它仍然是非常慢的,感觉像20。 我们的 Out 文件占用了芯片上的大部分可用闪存。 期待听到您对如何进行设计的想法。

我还发布了另一个有关 XDS200调试器的问题。 我不知道它是否有一定的相关性,但这个问题已经困扰了我们多年,由于上述原因,我认为我应该尝试解决另一个问题。  另一个主题位于

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1239692/msp432-debuggers-how-to-ensure-that-xds200-and-xds110-probes-are-properly-configured-and-optimized-for-peak-performance

你好，Paul。 感谢您提供额外的数据。 我们最初认为这可能与调试器处理压缩符号的方式有关。  您的信息不支持该理论。 在符号加载阶段、调试器正在读取和解码 输出文件中包含的 DWARF 信息。 构建了内部数据结构、以便在调试会话期间快速查找符号信息。  本质上、有很多磁盘读取活动、数据被拉入内存。

令人好奇的是、该问题仅影响您的 PC、并且在没有其他明显更改的情况下开始发生。 此类事情以前的罪魁祸首是安全软件(AV 扫描仪、权限访问管理器、端点保护等)、系统路径变量中的额外内容以及为各种目的插入的 Windows 挂钩 DLL (假设您正在使用 Windows)的干扰。

如果您可以 生成调试服务器日志 并将其提供给我们、我们可以缩小使用时间的范围。 日志将是巨大的,但压缩良好(特别是与7z )。 可以在此处上传日志、也可以提供一个共享驱动器位置供您上传日志。

下面还有一些其他的事情可以尝试帮助缩小问题的范围： (1)您是否能够暂时禁用您正在使用的 AV 或端点保护软件并重新测试符号负载？ 这实际上是最可能的问题。 (2)从命令提示符启动"ccstudio．exe"、但简化路径变量以仅包含严格需要的项目并删除所有其他内容。 (3)调查正在加载哪些钩子 DLL -可能将此保留为最后的手段。

我们来看一下另一个线程。

你好、Andy。  我非常感谢所有的反馈。  我已根据您的请求上传了调试服务器日志。  我已经明确考虑了 AV 扫描器/端点保护的可能性是一个重要因素。  很长一段时间以前、我们能够临时禁用它。  我最近又研究了一下它、看看我是否有某种方法可以禁用它、我找不到任何方法。  根据您的反馈、我现在将在我们的 IT 支持团队中遇到开 TT 的麻烦(这可能是一个艰巨的过程、这就是我通常避免开 TT 的原因、除非我别无选择)、 询问在我通过调试探针加载 out 文件时、他们是否可以禁用任何防病毒功能、看看这些功能显示了什么。  另一个原因是,我没有联系它有关这一点,我认为它应该也会影响我的同事,但也许 AV/端点保护配置因某种方式改变了我的机器上周五,而不是我的同事。   

Paul、我们看了调试程序的日志。 没有什么特别突出的花费了很长的时间。 时间花费在符号加载阶段(您已经知道)、但分散在各个操作之间。 将代码加载到目标大约需要27秒。 余数用于符号。  如果您收到支持请求单的任何地方、请更新我们。 我觉得你的痛苦在这里。

你好、Andy。  非常感谢您对日志的反馈。  从您上一篇文章中可以看到、我认为有很多磁盘读取活动是我遇到的性能问题的核心所在、这一点也很好。  我已经与我们的 IT 支持人员开了一个 TT。  该问题现已上报给有权禁用防火墙/防病毒等功能的人员。  我会尽快让你知道更多。

你好、Paul、团队注意到了日志中的其他东西。  在不详细了解这项功能的情况下、您是否能够尝试以下操作来查看其是否对您的情况有所帮助？

• 退出 CCS
• 从命令窗口中、设置环境变量 TI_DS_OFS_USE_THERIAL_FILE=1
• 从命令窗口启动 CCS (导航至 \ccs\eclipse 并运行 CCStudio.exe)
• 尝试慢速负载测试用例并寻找任何改进。

这需要的时间很长、但有助于减少读取次数、从而提高负载性能。

你好、Andy。  我尝试了上述步骤、其中涉及设置  TI_DS_OFS_USE_THERIAL_FILE=1、但没有 发现任何明显的改进。  我们的 IT 支持人员联系我、要求我提供更多信息、我已将他们定向至该主题。  我希望他们能够帮助我们。

感谢尝试 Andy 的建议。

请保持我们发布有关 IT 票证的信息。

谢谢

小

感谢您发送编修。  很高兴听到您说出了这个令人沮丧的问题、但很抱歉、您不得不浪费这么多时间来解决它。 这些 TI 调试探针使用 Microsoft USB 驱动程序(使用不同的 VID/PID 进行定制)。 如果该另一个产品在 USB 级别上产生干扰、那么将难以跟踪。  

你好、Andy。  是的、很高兴有这个问题摆在我们后面。  这是有关使用 Microsoft USB 驱动程序的探头的非常有用的提示。  可以想象专门用于管理打印机驱动程序的服务如何通过 USB 积极执行某些操作不是一件难事。

不幸的是、即使该线程前面提到的 VPSX 服务仍然处于禁用状态、这个问题昨天在我的系统上又开始出现。  因此、不仅仅是 VPSX 服务、这个问题还涉及很多方面。

啊、很遗憾听到问题仍然存在。 这些类型的问题很难完全解决。

我之前和 AndyW 讨论过这个问题、想知道在*只*加载符号时是否会看到相同的问题("Run -> Load -> Load Symbols")。 如果您这样做、我们可以排除任何 USB 冲突、因为只加载符号不需要任何目标通信。

Ki 您好。  我上周在度假、这就是为什么我直到现在都没有回复的原因。  我非常感谢你继续思考这个问题。  

我的菜单中没有 Run->Load->Load Symbols、但我将调试配置 Loading Options 更改为"Load Symbols Only"、并且在运行配置时、符号仍然需要很长时间才能加载。  

使用我通常使用的配置时、我可以确认、将程序加载到目标中的行为与过去的行为没有变化。

请注意、加载符号不需要任何目标通信。  我仍然为这件事而苦恼。  我们的 IT 支持团队已作出响应、并表示他们希望与我一起参加培训。  我一定会继续跟进这一问题、让您知道情况如何。

Unknown 说：

我的菜单没有运行->加载->加载符号

该菜单项仅在活动的调试会话期间在 CCS Debug 透视图中可用。  

Unknown 说：

我将调试配置加载选项更改为"仅加载符号"，并且在运行配置时，符号仍需很长时间才能加载。  [/报价]

如果您正在执行基于项目的调试启动、那么这也就足够了。

Unknown 说：

请注意加载符号不需要任何目标通信。

您甚至可以通过执行 无工程(手动)调试启动 、然后在调试器启动后但在连接到目标之前仅加载符号来简化测试用例：

Unknown 说：

我们的 IT 支持团队已回复，并表示他们希望与我进行会话。  我一定会继续跟进,让你知道它是怎样的。

请继续关注我们。

谢谢

小

[/quote]

写了上述内容后不久,我尝试禁用/调整我的机器上的一些其他服务,我认为这些服务有可能干扰符号的加载,但这似乎没有任何立即产生影响,即使在多次重新启动和许多不同的实验之后。  在我与 IT 支持团队的初始会话中、他们暂时禁用了 Crowdstrik 端点保护、以查看是否偶然会产生影响、但问题仍然存在。  然后我被上报至更高一级的支持团队。 然后、我不得不在几天内处理其他任务、当我准备演示问题时、我无法再让问题发生！  符号加载在过去几天一直以正常速度进行。  希望问题不再出现。  如果是、我会重新发布。

novar luo 说：

您甚至可以通过执行 无项目(手动)调试启动 并在调试器启动后但在连接到目标之前仅加载符号来简化测试用例：

我对这一建议表示赞赏。  我还没有尝试过这个工作流程、但我会、因为我很好奇它是如何工作的。