与.data中的符号相比，gdb对于.bss中的符号的行为有所不同 [英] gdb behaves differently for symbols in the .bss, vs. symbols in .data

问题描述

我最近开始使用YASM学习用于Intel x86-64体系结构的汇编语言.在解决一本书(由雷·赛法斯(Ray Seyfarth)提出)中建议的一项任务时，我遇到了以下问题:

I recently started learning assembly language for the Intel x86-64 architecture using YASM. While solving one of the tasks suggested in a book (by Ray Seyfarth) I came to following problem:

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

When I place some characters into a buffer in the .bss section, I still see an empty string while debugging it in gdb. Placing characters into a buffer in the .data section shows up as expected in 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"

after LINE 2: x/s &str_test, result - 0x601030: "A"

&buf似乎没有评估为正确的地址，因此它仍然看到全零.根据其/proc/PID/maps，0x7ffff7dd2740不在正在调试的进程的BSS中，所以这没有任何意义. 为什么&buf评估为错误的地址，而&str_test评估为正确的地址?都不是全局"符号，但是我们确实使用调试信息进行构建.

It looks like &buf isn't evaluating to the correct address, so it still sees all-zeros. 0x7ffff7dd2740 isn't in the BSS of the process being debugged, according to its /proc/PID/maps, so that makes no sense. Why does &buf evaluate to the wrong address, but &str_test evaluates to the right address? Neither are "global" symbols, but we did build with debug info.

在x86-64 Ubuntu 15.10上使用GNU gdb(Ubuntu 7.10-1ubuntu2)7.10进行了测试.

Tested with GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 on x86-64 Ubuntu 15.10.

我要与之建立联系

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

可执行文件上的

nm显示正确的符号地址:

nm on the executable shows the correct symbol addresses:

$ 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！).

(editor's note: I rewrote a lot of the question because the weirdness is in gdb's behaviour, not the OP's asm!).

推荐答案

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

glibc includes a symbol named buf, as well.

(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 *的原因.

gdb happens to choose the symbol from glibc over the symbol from the executable. This is why ptype buf shows char *.

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

Using a different name for the buffer avoids the problem, and so does a global buf to make it a global symbol. You also wouldn't have a problem if you wrote a stand-alone program that didn't link libc (i.e. define _start and make an exit system call instead of running a ret)

请注意，0x00007ffff7dd6400(我系统上的buf地址；与您的系统不同)实际上不是 堆栈地址. 从外观上看，它看起来像一个堆栈地址，但不是:7 后有不同的f位数字.很抱歉在评论中出现混乱以及问题的早期编辑.

Note that 0x00007ffff7dd6400 (address of buf on my system; different from yours) is not actually a stack address. It visually looks like a stack address, but it's not: it has a different number of f digits after the 7. Sorry for that confusion in comments and an earlier edit of the question.

共享库也被加载到低47位的顶部附近虚拟地址空间的数量，靠近堆栈的映射位置.它们是位置无关的，但是库的BSS空间必须相对于其代码在正确的位置.再次仔细检查/proc/PID/maps，gdb的&buf实际上位于libc-2.21.so映射旁边的匿名内存的rwx块中(未映射到任何文件).

Shared libraries are also loaded near the top of the low 47 bits of virtual address space, near where the stack is mapped. They're position-independent, but a library's BSS space has to be in the right place relative to its code. Checking /proc/PID/maps again more carefully, gdb's &buf is in fact in the rwx block of anonymous memory (not mapped to any file) right next to the mapping for 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的指针)到达最终目的地.

A normal call instruction with a rel32 encoding can't reach a library function, but it doesn't need to because GNU/Linux shared libraries have to support symbol interposition, so calls to library functions actually jump to the PLT, where an indirect jmp (with a pointer from the GOT) goes to the final destination.

这篇关于与.data中的符号相比，gdb对于.bss中的符号的行为有所不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！