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

Question

我最近开始使用 YASM 学习 Intel 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 没有评估到正确的地址，所以它仍然看到全零。根据它的 /proc/PID/maps，0x7ffff7dd2740 不在被调试进程的 BSS 中，所以这没有意义。 为什么 &buf 计算出错误的地址，而 &str_test 计算出正确的地址 ？ "global" 符号也不是，但我们确实使用调试信息进行构建。

在 x86-64 Ubuntu 15.10.

上使用 GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 进行测试

我正在使用

构建

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 也是如此，使它成为一个全局符号。如果您编写了一个没有 link libc 的独立程序（即定义 _start 并进行退出系统调用而不是运行 a ret)

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

共享库也在的顶部加载，靠近堆栈映射的位置。它们与位置无关，但是库的 BSS space 必须相对于其代码位于正确的位置。再次仔细检查 /proc/PID/maps，gdb 的 &buf 实际上位于匿名内存的 rwx 块中（未映射到任何文件），就在 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共享库必须支持符号插入，所以calls 到库函数实际上跳转到 PLT，其中间接 jmp（带有来自 GOT 的指针）到达最终目的地。

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

gdb behaves differently for symbols in the .bss, vs. symbols in .data

x86

assembly

gdb

x86-64

yasm