C程序的GDB问题

发布于 2024-11-08 22:49:31 字数 2335 浏览 2 评论 0原文

在这里,我正在检查一个用 C 编写的简单程序,该程序将一个 char 指针保存到一个字符串,该字符串表示“Hello, world!\n”

这是我的 GDB 的输出...我对 GDB 的不一致和什么感到困惑就在这里:

$ gcc -g pointer.c
$ gdb -q ./a.out
Reading symbols for shared libraries .. done
(gdb) list
1   #include <stdio.h>
2   #include <string.h>
3   
4   int main() {
5     char str[20];
6     char *pointer;
7   
8     strcpy(str, "Hello, world!\n");
9     pointer = str;
10    printf("%s",pointer);
(gdb) 
11  }
(gdb) break 10
Breakpoint 1 at 0x100000ed1: file pointer.c, line 10.
(gdb) run
Starting program: /Users/___/a.out 
Reading symbols for shared libraries +. done

Breakpoint 1, main () at pointer.c:10
10    printf("%s",pointer);
(gdb) print pointer
$1 = 0x7fff5fbff950 "Hello, world!\n"
(gdb) print &pointer
$2 = (char **) 0x7fff5fbff948
(gdb) x/s 0x7fff5fbff950
0x7fff5fbff950:  "Hello, world!\n"
(gdb) x/16b 0x7fff5fbff950
0x7fff5fbff950:  "Hello, world!\n"
0x7fff5fbff95f:  ""
0x7fff5fbff960:  "x??_?"
0x7fff5fbff967:  ""
0x7fff5fbff968:  "՝?Y4?K\033???_?"
0x7fff5fbff977:  ""
0x7fff5fbff978:  "?\016"
0x7fff5fbff97b:  ""
0x7fff5fbff97c:  "\001"
0x7fff5fbff97e:  ""
0x7fff5fbff97f:  ""
0x7fff5fbff980:  ""
0x7fff5fbff981:  ""
0x7fff5fbff982:  ""
0x7fff5fbff983:  ""
0x7fff5fbff984:  ""
(gdb) x/x 0x7fff5fbff950
0x7fff5fbff950: 0x48
(gdb) x/x 0x7fff5fbff951
0x7fff5fbff951: 0x65
(gdb) x/s 0x7fff5fbff951
0x7fff5fbff951:  "ello, world!\n"
(gdb) print &pointer
$3 = (char **) 0x7fff5fbff948
(gdb) x/x 0x7fff5fbff948
0x7fff5fbff948: 0x00007fff5fbff950
(gdb) x/x 0x7fff5fbff949
0x7fff5fbff949: 0x4800007fff5fbff9
(gdb) x/2x 0x00007fff5fbff950
0x7fff5fbff950: 0x77202c6f6c6c6548  0x00000a21646c726f

我的问题是:

内存中的这些位置之一存储了多少字节的信息?当我到达地址时 0x7fff5fbff950,内容显示为 0x48(ASCII 'H')。那么这是否意味着每个内存地址只存储一个字节的信息?好的。我们假设确实如此。然后我在 print &pointer: 0x7fff5fbff948 给出的地址上运行相同的“x/x”命令

,我得到值 0x00007fff5fbff950,我认为(忽略前导零)是“Hello, world!\n”的开头内存中的字符串。

现在0x00007fff5fbff948怎么可能包含0x00007fff5fbff950并且仍然只有一个字节的内存呢?所以我查看 0x00007fff5fbff949... 现在这再次告诉我,我们每次只查看一个字节,因为我们丢失了尾随的 0x50 (我知道小端,所以也许我的措辞令人困惑)。

现在我真的很生气...我尝试执行 x/2x 0x7fff5fbff948 ,但我受到了两个巨大的十六进制数字的攻击...

所以内存中的数据一次存储一个字节,不知何故 x/x 有时会给我一个字节每个内存字节,有时给我一个完整的地址?如何控制调试器的输出内容? x/x 应检查该地址的内容并以十六进制输出。我可以使用 x/b 表示单个字节,x/2b 表示 2 个字节...但是 x/2x 意味着什么?

抱歉意识流问题......希望有人能帮助我解决这个问题。

Here I'm examining a simple program written in C that saves a char pointer to a string that says "Hello, world!\n"

Here is the output of my GDB... I'm confused at the inconsistency of GDB and what's right here:

$ gcc -g pointer.c
$ gdb -q ./a.out
Reading symbols for shared libraries .. done
(gdb) list
1   #include <stdio.h>
2   #include <string.h>
3   
4   int main() {
5     char str[20];
6     char *pointer;
7   
8     strcpy(str, "Hello, world!\n");
9     pointer = str;
10    printf("%s",pointer);
(gdb) 
11  }
(gdb) break 10
Breakpoint 1 at 0x100000ed1: file pointer.c, line 10.
(gdb) run
Starting program: /Users/___/a.out 
Reading symbols for shared libraries +. done

Breakpoint 1, main () at pointer.c:10
10    printf("%s",pointer);
(gdb) print pointer
$1 = 0x7fff5fbff950 "Hello, world!\n"
(gdb) print &pointer
$2 = (char **) 0x7fff5fbff948
(gdb) x/s 0x7fff5fbff950
0x7fff5fbff950:  "Hello, world!\n"
(gdb) x/16b 0x7fff5fbff950
0x7fff5fbff950:  "Hello, world!\n"
0x7fff5fbff95f:  ""
0x7fff5fbff960:  "x??_?"
0x7fff5fbff967:  ""
0x7fff5fbff968:  "՝?Y4?K\033???_?"
0x7fff5fbff977:  ""
0x7fff5fbff978:  "?\016"
0x7fff5fbff97b:  ""
0x7fff5fbff97c:  "\001"
0x7fff5fbff97e:  ""
0x7fff5fbff97f:  ""
0x7fff5fbff980:  ""
0x7fff5fbff981:  ""
0x7fff5fbff982:  ""
0x7fff5fbff983:  ""
0x7fff5fbff984:  ""
(gdb) x/x 0x7fff5fbff950
0x7fff5fbff950: 0x48
(gdb) x/x 0x7fff5fbff951
0x7fff5fbff951: 0x65
(gdb) x/s 0x7fff5fbff951
0x7fff5fbff951:  "ello, world!\n"
(gdb) print &pointer
$3 = (char **) 0x7fff5fbff948
(gdb) x/x 0x7fff5fbff948
0x7fff5fbff948: 0x00007fff5fbff950
(gdb) x/x 0x7fff5fbff949
0x7fff5fbff949: 0x4800007fff5fbff9
(gdb) x/2x 0x00007fff5fbff950
0x7fff5fbff950: 0x77202c6f6c6c6548  0x00000a21646c726f

My questions are:

How many bytes of information is stored in one of these locations in memory? When I'm at the address
0x7fff5fbff950, the contents appear to be 0x48 (ASCII 'H'). So does that mean, per memory address, only a byte of information is stored? OK. Let's assume it does. Then I run the same "x/x" command on the address given by print &pointer: 0x7fff5fbff948

I got value 0x00007fff5fbff950, which I recognize (ignoring the leading zeros) to be the beginning of the "Hello, world!\n" string in memory.

Now how can 0x00007fff5fbff948 contain 0x00007fff5fbff950 and still have only one byte of memory? So I look at 0x00007fff5fbff949... and this now tells me again that we're only looking at a byte each time, since we lost the trailing 0x50 (I know little-endian so maybe I'm wording this confusingly).

Now I get really mad... I try to do x/2x 0x7fff5fbff948 and I'm attacked with two gigantic hexadecimal numbers...

So data in memory is stored byte at a time, and somehow x/x will sometimes give me one byte per memory and sometimes give me an entire address? How can I control what the debugger will output? x/x should be examine the contents of this address and output in hexadecimal. I can use x/b for a single byte, x/2b for 2 bytes... but x/2x means what?

Sorry for the stream of consciousness questions.. hopefully someone can help me clear this up.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

网名女生简单气质 2024-11-15 22:49:31

内存是字节可寻址的,这意味着每个字节都有一个不同的地址。然后您可以解释将一对字节解释为 16 位整数,将四个字节解释为 32 位整数,等等。该格式说明符可以让您做到这一点 - 根据您的需要打印内存内容对它的解释。因此,x/2x 0x7fff5fbff948 将打印两个字大小(此处为 64 位)整数,第一个在地址 0x7fff5fbff948 处,第二个在地址 0x7fff5fbff950 处。

Memory is byte addressable meaning each byte has a distinct address. Then you can interpret say a pair of bytes as a 16-bit integer, four bytes as a 32-bit integer, etc. That format specifier lets you do just that - print content of memory according to your interpretation of it. So x/2x 0x7fff5fbff948 will print two word-size (here 64-bit) integers, first at address 0x7fff5fbff948, and second at address 0x7fff5fbff950.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文