供应商以.so 库文件的形式提供给我们的相机设备的设备驱动程序。
只有带有 API 的头文件可用，它提供了我们可以使用该设备的功能列表。我们的应用程序与供应商提供的.so 库文件链接，并使用为我们的目标提供的接口函数。
当我们想测量我们的应用程序处理不同任务所花费的时间时，我们添加了 GCC -pg 标志并编译+构建了我们的应用程序。
但是我们发现，使用这个使用-pg 构建的可执行文件，我们观察到相机图像获取功能出现随机故障。由于我们使用的是.so 库文件，因此我们不知道该函数内部出了什么问题。
所以总的来说，我想了解这种故障模式的可能原因是什么。任何可以帮助进行分析及其副作用的指针或文档都值得赞赏。
【问题讨论】：
This answer 是对 gcc -pg 标志分析器实际工作方式的有用概述。关键点主要与时间可能发生的变化有关。如果您的库中有任何时间敏感性，那么引入分析器开销可能会改变执行部分代码所需的时间，并且可能违反某种约束。
【讨论】：
如果你看gprofdocumentation，它会解释实现细节：
分析通过改变程序中每个函数的方式来工作 编译以便当它被调用时，它会隐藏一些 从哪里调用它的信息。由此，分析器 可以算出调用它的函数，并且可以数出多少次 它被称为。当您的程序时，编译器会进行此更改 使用 `-pg' 选项编译，这会导致每个函数调用 mcount（或 _mcount 或 __mcount，取决于操作系统和编译器）为 它的第一个操作之一。
因此，当您打开-pg 时，您的应用程序的时间会发生很大变化。
如果您想在不显着影响时序的情况下检测您的代码，您可以查看oprofile。它不会像gprof 那样造成显着的开销。
另一个相当新的工具是一个很好的轻量级分析工具是perf。
分析工具主要用于了解库/应用程序的 CPU 绑定部分，并且可以帮助您优化这些关键部分。大多数时候，它们用于识别一些浪费 CPU 周期的罪魁祸首函数/方法。所以不要将它作为调试任何和所有问题的唯一部分。
大多数供应商库还将提供在运行时打开额外调试或转储额外信息的方法。它们包括环境变量、日志文件、驱动程序的/proc 或/sys 接口等手段，有时甚至是在运行时提高调试级别的工具。看看你是否可以利用这些。
如果您在库/驱动程序中定义了 API，您应该对它们运行单元测试，而不是尝试调试您构建的整个应用程序。
如果您发现某个单元测试失败，请将单元测试的源代码发送给您的供应商，并要求他们修复错误。如果这不是错误，您的供应商至少会为您指出正确的 API 集或要使用的语义。
【讨论】：