NASM x86_64在32位模式下组装：为什么该指令产生RIP相对寻址代码？

Question

[bits 32]
    global _start

    section .data
    str_hello       db  "HelloWorld", 0xa
    str_hello_length    db      $-str_hello

    section .text

    _start:

        mov ebx, 1              ; stdout file descriptor
        mov ecx, str_hello      ; pointer to string of characters that will be displayed        
        mov edx, [str_hello_length] ; count outputs Relative addressing
        mov eax, 4              ; sys_write
        int 0x80                ; linux kernel system call

        mov ebx, 0  ; exit status zero
        mov eax, 1  ; sys_exit
        int 0x80    ; linux kernel system call

这里的基本要点是我需要将hello字符串的长度传递给linux的sys_write系统调用。现在，我很清楚我可以使用EQU，它会工作正常，但我真的想了解这里发生了什么。

所以，基本上当我使用EQU时，它会加载值，这很好。

str_hello_length equ $-str_hello
...
...
mov edx, str_hello_length

但是，如果我将此行与DB一起使用

str_hello_length db $-str_hello
...
...
mov edx, [str_hello_length]     ; of course, without the brackets it'll load the address, which I don't want. I want the value stored at that address

而不是像我期望的那样在该地址加载值，汇编器输出RIP相对寻址，如gdb调试器中所示，我只是想知道为什么。

mov    0x6000e5(%rip),%edx        # 0xa001a5

现在，我尝试使用eax寄存器（然后将eax移动到edx），但后来我遇到了另一个问题。我最终得到了一个分段错误，如gdb中所述：

movabs 0x4b8c289006000e5,%eax

显然，不同的寄存器产生不同的代码。我想我需要以某种方式截断高32位，但我不知道该怎么做。

虽然有点找到了'解决方案'，但它是这样的：用str_hello_length的地址加载eax，然后加载eax指向的地址内容，一切都是hunky dory。

mov eax, str_hello_length       
mov edx, [eax]  ; count


; gdb disassembly
mov    $0x6000e5,%eax
mov    (%rax),%edx

显然试图从mem地址间接加载一个值产生不同的代码？我真的不知道。

我只需要帮助理解这些指令的语法和操作，这样我就可以更好地理解为什么如何加载有效地址。是的，我想我可以切换到EQU并以我的快乐方式，但我真的觉得我不能继续，直到我理解DB声明发生了什么并从它的地址加载。

Answer 1

另一答案

Answer 2

另一答案