【问题标题】:I can't understand the output of gdb我无法理解 gdb 的输出
【发布时间】:2015-11-13 18:59:34
【问题描述】:

我现在只是想学习使用 gdb。我正在使用的程序运行良好;我不想调试它或任何东西;我只是在测试 gdb 的功能。这是源代码:

#include <stdio.h>
#include <ctype.h>
#include <string.h>

int main( int argc, char **argv ){
        int wordcount = 0;
        int len = strlen( argv[1] );
        for( int i = 0; i < len; i++ ){
                if( isspace( argv[1][i] ) && !isspace( argv[1][i-1] ) ) 
                        wordcount++;
        }   
        if( !isspace( argv[1][len-1] ) ) wordcount++;
        if( wordcount == 0 && len > 0 ) // if all characters were non-whitespace,
                wordcount = 1;          // then there was exactly one word
        printf( "%d\n", wordcount );
        return 0;
}   

我启动 gdb 并运行程序,在第 7 行和第 9 行设置断点。我使用了 backtrace 和 step 命令,但我根本不理解它们的输出。当我输入“backtrace full”时,gdb 给了我这个:

#0  _start () at ../sysdeps/i386/elf/start.S:65
No locals.

这到底是什么意思?什么是_start?什么是../sysdeps/i386/elf/start.S:65?当我明确声明 wordcount 和 len 时,怎么可能没有本地人?我试过谷歌,但我在 gdb 上找到的每个教程都显示它产生的输出与我得到的完全不同(更详细)。当我用谷歌搜索得到的字符串时,我会得到一堆关于 ARM 架构的结果。

【问题讨论】:

  • 确保使用调试符号进行编译——在 GCC 上,这是每个编译命令的 -g 标志。
  • 或者更好的是,使用-ggdb
  • 错误出现在for循环的开头。如果i0,那么i-1 会是什么?该索引超出范围。
  • 好的,-g 选项似乎提供了更明确的输出。还没有尝试过-ggdb。是的,当你指出它时,我注意到程序中的错误,ott。这应该很容易解决。不过我只写了测试gdb的程序,所以错误并不重要。
  • @ott:是的,但 OP 并没有询问代码的正确性。这是一个微妙的错误;只有当命令行参数的第一个字符是空格时它才会跳闸,并且你必须努力做到这一点。它可以被故意触发;不可能是偶然的。可能是一个安全问题,具体取决于用例。

标签: c gdb


【解决方案1】:

我正在使用的程序运行良好;

对于作品的一些定义。您的程序至少有 2 个错误。

当我输入“backtrace full”时,gdb 给了我这个:... 这到底是什么意思?

如果不知道您达到这一点之前使用了哪些命令,很难判断。很可能您在从main 返回之前执行了next,因此进入了_start(这是调用main 的例程,并且通常是任何程序的执行开始的地方)。

什么是../sysdeps/i386/elf/start.S:65?

_start 例程是 GLIBC 的一部分,在 sysdeps/i386/elf/start.S 源文件中定义。

当我明确声明 wordcount 和 len 时,怎么可能没有本地人?

不是main 中,因此main 中存在的任何本地人都是无关紧要的:它们仅在main 执行时才处于活动状态,而不是(或者还没有,或者不再)。

【讨论】:

  • "对于作品的一些定义。你的程序至少有 2 个错误。"我可以看到边界检查错误。另一个在哪里?
  • @ZenHacker argv[1] 可能是NULL,在这种情况下strlen 会崩溃。 argv[1] 可能以空格开头,在这种情况下,argv[1][-1] 将被访问。
  • 好的,感谢您指出这一点。我倾向于成为一个有点草率的程序员。
  • @ZenHacker :这里有人似乎提供了帮助。如果他们给你的答案帮助解决了你的问题,你不妨考虑接受它。
  • @ZenHacker 太棒了。谢谢,它有助于跟踪已解决/未解决的问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-03-25
  • 2021-07-16
  • 1970-01-01
  • 1970-01-01
  • 2021-03-08
  • 2013-12-23
相关资源
最近更新 更多