使用 lldb 打印变量的内容

Question

好的，所以这听起来像是一个愚蠢的问题，但我被困住了：我在 lldb 调试会话期间无法读取变量的值（gdb 工作正常）。

我找到了其他人的帖子，他们遇到了与我相同的错误消息，但不同的是，我什至不知道如何打印出最简单形式的变量的值。

为了更好地表达我的问题，我将在这里考虑一个非常简单的示例。我们有一个包含以下代码的文件“main.c”：

#include <stdlib.h>
#include <stdio.h>

int main(void) {
  int a = 1;
  int b = 2;
  int c = 0;
  c = a + b;
  c = c*b;
  printf("c = %d\n", c);
  return 0;
}

我使用它编译它：

user@machine ~ $ gcc -g main.c

一个名为的二进制文件 “a.out” 生成

然后我 ivoque lldb ：

user@machine ~ $ lldb-3.4 ./a.out

我想在第 9 行停下来读取 c 的值。因此，我首先添加一个断点：

(lldb) breakpoint set -f main.c -l 9

然后我运行代码：

(lldb) run

到目前为止，一切都按预期进行。现在是棘手的部分：我想读取变量 c 的值。因此，我写：

(lldb) print c

然后 lldb 返回我：

error: use of undeclared identifier 'c'
error: 1 errors parsing expression

当然：

(lldb) expression c

返回完全相同的错误信息。

有什么我错过的吗？任何帮助将不胜感激。

我的设置：

• lldb：“lldb 版本 3.4（修订版）”（包 v.：“3.4~svn183914-1ubuntu1”）
• gcc : "gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1" (package v. : "4.8.1-2ubuntu3")
• （我的仓库是linux mint 16默认提供的）

---

@Sean Perry 的回答提供了更多信息：

1：附加选项 -O0 似乎不会改变调试器的行为。

2：我也尝试使用以下虚拟代码代替我之前的代码

#include <stdlib.h>
#include <stdio.h>

int main(void) {
  long a = 1;
  long b = 2;
  long c = 0;
  c = a + b;
  c += (long) &c;
  printf("c = %ld\n", c);
  return 0;
}

我不确定@Sean Perry 所说的“使用指针”是什么意思，但我认为它必须阻止代码优化，因为每次运行二进制文件时变量 c 的地址（或多或少）都会随机更改。

3：最后，我注意到了一些有趣的事情：

• 使用 gcc [-g -O0] 编译，然后使用 gdb 进行调试：可行
• 使用 gcc [-g -O0] 编译然后使用 lldb 调试：不起作用
• 使用 clang [-g -O0] 编译然后使用 gdb 调试：工作
• 使用 clang [-g -O0] 编译然后使用 lldb 调试：工作

edit1：回复@SeanPerry edit2 : 区分软件版本和软件包版本

Answer 1

这段代码非常简单，我敢打赌 llvm 已经完全删除了变量。尝试在禁用优化 (-O0) 的情况下进行编译，看看是否有帮助。除此之外，使用指针或做一些更复杂的事情，这样编译器就不会删除你的数学并用预先计算的值替换它。

Answer 2

似乎这是使用gcc 4.8.1 和lldb-3.4 时的特定问题

使用gcc-4.8.2 和gcc-4.7.3 可以正常工作。

Answer 3

调查您所看到的行为的最佳方法是查看调试信息。在 Mac OS X 系统上，如果您没有创建 dSYM，您将在 .dSYM 包或 .o 文件上运行 dwarfdump。调试信息包含从编译器到调试器的关于在何处查找变量的指令。

在实时进程中，使用 lldb，您可以使用 image lookup -v -a $pc（或简称为 im loo -va $pc）让 lldb 向您显示所有局部变量的存储位置（以 DWARF 位置表达式语言表示）。

如果有一个程序 gdb 不能打印变量而 lldb 在同一个 pc 地址 不能，这听起来可能是一个 lldb 错误。调试信息是关于变量存储在哪里以及它们“存活”多长时间的最终事实（就调试器而言）。在优化的代码中，它们可能只存在于您函数的非常短的部分。

从 hack 的角度来看，真正的来源是阅读汇编代码。通常，在优化下，编译器不会尽可能地跟踪变量的位置——它可能说某个变量在给定的 pc 地址不可用，但如果你阅读程序集足够接近，您可能会发现仍然保存在堆栈中的最后一个值的副本等。