【发布时间】：2016-08-30 06:35:19
【问题描述】：
我最近开始使用 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 没有评估到正确的地址，所以它仍然看到全零。根据其/proc/PID/maps，0x7ffff7dd2740 不在被调试进程的 BSS 中，所以这没有任何意义。 为什么&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！）。
【问题讨论】：
-
我基本上重写了这个问题，因为你的 asm 正在工作。问题是 gdb 中的
&buf是堆栈上的一些奇怪地址。0x7ffff...地址是 x86-64 Linux 中的堆栈地址。 bss 和数据地址始终位于低 2GB 中（因此它们适合有符号的 32 位整数，因为许多 x86-64 指令使用符号扩展的imm32立即数。例如，add rax, symbol使用add r/m64, imm64编码）。无论如何，我在自己的 x86-64 桌面上测试了自己，并重现了 gdb 的怪异之处，但没有找到在 gdb 表达式中获取正确地址的方法buf。 -
您得到错误地址的另一个线索是它是 16B 对齐的（最后一个十六进制数字是 0），但我们知道
buf不应该这样。它跟在resb 75之后，bss 的开头通常是 16B 对齐的（我们可以看到result在 nm 输出中。是的，这些符号地址是每次运行时实际映射可执行文件的位置它，因为它不可重定位。Linux 可执行文件的代码不必与位置无关，不像动态库需要那样（使用-fPIC编译，或避免手写 asm 中的绝对地址）。） -
谢谢，彼得，据我所知，这是一种 gdb 行为，是否可以处理它并以某种方式将字符放在 .bss 部分。堆栈中 buf 的位置不正确而不是 .bss 真的让我很恼火，而且我不明白为什么会这样。我应该以某种方式对齐 buf 吗？
-
你的 asm 完全按照你的想法去做。唯一的问题是让 gdb 向您显示地址
0x060108b的内容，方法是输入涉及 buf 的内容，而不是复制/粘贴数字地址。我跑了x /s 0x0060108b，得到了x60108b: "A" -
注意反汇编中可以看到数字地址。我的
~/.gdbinit中有set disassembly-flavor intel和layout reg，所以我不必使用disas命令来查看关于当前RIP 的反汇编指令。
标签： assembly x86 gdb x86-64 yasm