【问题标题】:Weird lldb behavior (comparing to gdb) C奇怪的 lldb 行为(与 gdb 相比)C
【发布时间】:2016-04-09 23:14:01
【问题描述】:

我来自freebsd,习惯用GDB调试,可惜我的macbook上GDB不是natif,我想用LLDB调试。

很遗憾,我不明白这种奇怪的行为:

当我启动一个 C 程序并在一个函数上设置断点,然后使用“运行”启动它时,我会转到断点,但看起来我可以通读但在汇编代码中 = 硬调试,而不是就像在 GDB 中一样,它是直线的 => 易于调试

看看.c,(我知道这段代码很糟糕,但这不是重点,只是为了尝试正确设置lldb)

int ft_count_point(char *m, int i)
{
    int count;
    int count_c;

    count = 0;
    count_c = 0;
    while (m[i] != '\0' || (m[i] != '\n' && m[i + 1] != '\n'))
    {
        if (m[i] == '.')
        {
            count_c++;
            count++;
        }
        if (m[i] == '\n' || m[i] == '#')
            count++;
        i++;
    }
    if (count != 20 && count_c != 16)
        return (1);
    exit (0);
}

主函数只包含对该函数的调用并返回 0。

看看我在 ft_count_point 上使用带有断点的 lldb 得到了什么:

(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) settings set -- target.run-args  "tests/error1"
(lldb) b ft_count_point
Breakpoint 1: where = a.out`ft_count_point + 35
    at ft_count_point.c:5, address = 0x00000001000073e3
(lldb) r
Process 17302 launched: './a.out' (x86_64)
AddressSanitizer debugger support is active. Memory error breakpoint
has been installed and you can now use the 'memory history' command.
Process 17302 stopped
* thread #1: tid = 0x43c1e7, 0x00007fff5fc01000 dyld`_dyld_start,
                   stop reason = exec
    frame #0: 0x00007fff5fc01000 dyld`_dyld_start
dyld`_dyld_start:
->  0x7fff5fc01000 <+0>: popq   %rdi
    0x7fff5fc01001 <+1>: pushq  $0x0
    0x7fff5fc01003 <+3>: movq   %rsp, %rbp
    0x7fff5fc01006 <+6>: andq   $-0x10, %rsp

我可以一步一步来,但说真的,这是浪费时间。

【问题讨论】:

  • 可执行文件中是否启用了符号调试信息?
  • 不知道,和我的~/.lldbinit 配置文件有关系吗?
  • 您确实有调试信息。您可以判断,因为 lldb 为您的断点找到了文件和行号。如果您没有调试信息,它只会是一个地址。

标签: c macos debugging gdb lldb


【解决方案1】:

看起来您的程序本身是重新执行的 - 也许这实际上是 ASAN 正在为您做的事情?您可以在 lldb 输出中看到这一点,其中显示:

* thread #1: tid = 0x43c1e7, 0x00007fff5fc01000 dyld`_dyld_start,
                   stop reason = exec

如果您确实遇到了断点,原​​因将是 stop reason = breakpoint 1.1 或任何合适的断点编号。

在 lldb 中,我们在重新执行时停止,我的猜测是 gdb 在执行后自动继续,这就是为什么您在 gdb 中没有注意到这一点。您应该能够继续,并且您将在稍后到达真正的断点。

有一个设置来控制是否继续通过 exec 可能是个好主意。随时向 lldb.llvm.org 错误报告者提交错误。

【讨论】:

  • 我在 macOS 上调试 arducopter 时看到了这一点。现在有一个选项可以防止这种情况发生吗?快把我逼疯了!
  • 啊,我看到stackoverflow.com/a/57065760/5325222 有答案了
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-03-10
  • 1970-01-01
  • 1970-01-01
  • 2018-09-04
  • 2017-04-09
  • 1970-01-01
  • 2012-04-27
相关资源
最近更新 更多