assembly - gdb 对 .bss 中的符号和 .data 中的符号的行为不同

Question

我最近开始使用 YASM 学习英特尔 x86-64 架构的汇编语言。在解决一本书(作者 Ray Seyfarth)中建议的一项任务时，我遇到了以下问题:

当我将一些字符放入 .bss 部分的缓冲区时，在 gdb 中调试它时我仍然看到一个空字符串。将字符放入 .data 部分的缓冲区中会按预期显示在 gdb 中。

segment .bss
result  resb    75
buf resw    100
usage   resq    1

    segment .data
str_test    db 0, 0, 0, 0

    segment .text
    global main
main:
    mov rbx, 'A'
    mov [buf], rbx          ; LINE - 1 STILL GET EMPTY STRING AFTER THAT INSTRUCTION
    mov [str_test], rbx     ; LINE - 2 PLACES CHARACTER NICELY. 
    ret

在 gdb 中我得到:

• 在第 1 行之后:x/s &buf , 结果 - 0x7ffff7dd2740 <buf>: ""

• 在第 2 行之后:x/s &str_test , 结果 - 0x601030: "A"

看起来像&buf没有评估到正确的地址，所以它仍然看到全零。 0x7ffff7dd2740 不在被调试进程的 BSS 中，根据其 /proc/PID/maps ，所以这没有意义。 为什么 &buf评估到错误的地址，但是 &str_test评估到正确的地址？也不是“全局”符号，但我们确实使用调试信息进行构建。

在 x86-64 Ubuntu 15.10 上使用 GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 测试。

我正在 build

yasm -felf64 -Worphan-labels -gdwarf2 buf-test.asm
gcc -g buf-test.o -o buf-test

nm在可执行文件上显示正确的符号地址:

$ nm -n  buf-test     # numeric sort, heavily edited to omit symbols from glibc
...
0000000000601028 D __data_start
0000000000601038 d str_test
... 
000000000060103c B __bss_start
0000000000601040 b result
000000000060108b b buf
0000000000601153 b usage

(编者注:我重写了很多问题，因为奇怪的是 gdb 的行为，而不是 OP 的 asm!)。

Answer 1

glibc 还包含一个名为 buf 的符号。

(gdb) info variables ^buf$
All variables matching regular expression "^buf$":

File strerror.c:
static char *buf;

Non-debugging symbols:
0x000000000060108b  buf            <-- this is our buf
0x00007ffff7dd6400  buf            <-- this is glibc's buf

gdb 碰巧选择了 glibc 中的符号而不是可执行文件中的符号。这就是 ptype buf 显示 char * 的原因。

为缓冲区使用不同的名称可以避免这个问题，global buf 也可以使它成为一个全局符号。如果您编写了一个没有链接 libc 的独立程序，您也不会有问题(即定义 _start 并进行退出系统调用而不是运行 ret)

---

请注意，0x00007ffff7dd6400(我系统上 buf 的地址；与您的不同)实际上不是堆栈地址。 它在视觉上看起来像一个堆栈地址，但它不是:它在 7 之后有不同数量的 f 数字。对于评论中的困惑和问题的早期编辑，我们深表歉意。

共享库也在 the low 47 bits of virtual address space 的顶部附近加载，靠近堆栈映射的位置。它们与位置无关，但库的 BSS 空间必须位于与其代码相关的正确位置。再次仔细检查 /proc/PID/maps，gdb 的 &buf 实际上位于匿名内存的 rwx block 中(未映射到任何文件)，就在映射旁边libc-2.21.so.

7ffff7a0f000-7ffff7bcf000 r-xp 00000000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7bcf000-7ffff7dcf000 ---p 001c0000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dcf000-7ffff7dd3000 r-xp 001c0000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dd3000-7ffff7dd5000 rwxp 001c4000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dd5000-7ffff7dd9000 rwxp 00000000 00:00 0        <--- &buf is in this mapping
...
7ffffffdd000-7ffffffff000 rwxp 00000000 00:00 0              [stack]     <---- more FFs before the first non-FF than in &buf.

带有rel32编码的普通call指令无法访问库函数，但不需要，因为GNU/Linux共享库必须支持符号插入，所以call s 到库函数实际上跳转到 PLT，其中一个间接 jmp(带有来自 GOT 的指针)转到最终目的地。