3

我最近开始使用 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 中我得到：

  • 在 LINE 1: 之后x/s &buf，结果 -0x7ffff7dd2740 <buf>: ""

  • 在 LINE 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 进行测试。

我正在建造

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！）。

4

1 回答 1

3

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 *。

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

请注意，0x00007ffff7dd6400（buf我系统上的地址；与您的不同）实际上不是堆栈地址。 它在视觉上看起来像一个堆栈地址，但它不是：它f在7. 很抱歉评论中的混乱和问题的早期编辑。

共享库也加载在虚拟地址空间的低 47 位顶部附近，靠近堆栈映射的位置。它们与位置无关，但库的 BSS 空间必须相对于其代码位于正确的位置。/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 共享库必须支持符号插入，所以call库函数实际上跳转到 PLT，其中间接jmp（与来自 GOT 的指针）到达最终目的地。

于 2016-08-30T10:01:19.570 回答