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中我得到：

：x/s &buf，结果 - 0x7ffff7dd2740 <buf>: ""
：x/s &str_test，结果 - 0x601030: "A"

看起来&buf没有评估到正确的地址，所以它仍然会看到全零。根据其/proc/PID/maps，0x7ffff7dd2740不在被调试进程的BSS中，因此没有意义。 为什么&buf评估错误的地址，但&str_test评估到正确的地址？全球＆＃34;全球＆＃34;符号，但我们使用调试信息构建。

在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也可以使其成为全局符号。如果你编写了一个没有链接libc的独立程序（即定义_start并进行退出系统调用而不是运行ret），你也不会遇到问题。

请注意0x00007ffff7dd6400（我系统上buf的地址;与您的系统不同）不实际上是堆栈地址。 它在视觉上看起来像堆栈地址，但它不是：它在f 之后的7位数不同。对于评论中的混淆以及之前对问题的编辑感到抱歉。

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

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共享库必须支持符号插入，因此{{1库函数实际上跳转到PLT，其中间接call（带有来自GOT的指针）进入最终目的地。

gdb对.bss中的符号与.data

1 个答案: