☰

尽管源代码可用，但 gdb 不会进入函数

tag-icon • tag-icon debugging gdb clang
尽管源代码可用，但 gdb 不会进入函数

我有一个编译的共享库，-g -O0包括：

void MyClass::whatever()
{
  ...
  doSomething(myImage, myPoints);
  ...
}

bool MyClass::doSomething(const Image& image, std::vector<cv::Vec2f>& points) const
{ 
  const int32_t foo = 1;
  const float   bar = 0.1f;
  ...
}

现在我正在单步执行whatever()，s但它并没有单步进入doSomething()，而是超越了它。这不是源可用性的问题，因为（1）它位于同一个文件中，并且（2）我可以设置一个断点doSomething()并毫无问题地单步执行源。但s似乎相信没有可用的来源。

如果我set step-mode on，我会得到类似的输出

0xb5d51148 in myClass::doSomething (this=0xb25e4, image=..., 
points=std::vector of length -91315, capacity 372871920 = {...})
from /path/to/myclass.so

就像没有可用来源时所得到的那样。几次初始化后，n将foo显示源代码。因此，放在函数开头的inline参数（类型、发布版本）可能有一些魔力。opencv是否有可能gdb看到这个东西，认为“奇怪的东西，让我们在这个函数之后继续”，并且没有发现大多数函数确实有可用的源代码？

（如果重要的话，它是在带有 Ubuntu 的 ARM 机器上使用 LLVM/clang 3.5 编译的）

答案1

这很可能是 gcc 优化和后续的问题行号表由...制作矮人 那个地图

包含程序可执行代码的内存地址以及与这些地址对应的源代码行

（第 8 页）

最简单的解决方案是使用斯泰皮当达到函数时

从GDB用户手册（第 65 页）

步

继续运行程序，直到控制到达不同的源代码行，然后停止它并将控制返回给 gdb。

....

步骤命令仅在源代码行的第一条指令处停止。这可以防止在 switch 语句、for 循环等中可能发生的多次停止。如果在行内调用具有调试信息的函数，则步骤将继续停止。换句话说，step 会进入该行内调用的任何函数。

此外，只有当函数有行号信息时，step 命令才会进入该函数。否则它的行为就像下一个命令。这可以避免在 MIPS 计算机上使用 cc -gl 时出现问题。以前，如果存在有关例程的任何调试信息，则单步进入子例程。

相关内容