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