时间戳

首页 > 解决方案 > 使用天然气进行进口的正确方法

assembly - 使用天然气进行进口的正确方法

问题描述

根据我之前的两个问题——一个与导入常量有关，一个与导入函数有关——在 x86 中使用气体导入常量以及为什么这个程序会循环？，我想知道以下是否准确地总结了如何as在程序集中使用示例进行导入：

# constants.s
SYS_EXIT        = 60
SYS_WRITE       = 1
STDOUT_FILENO   = 1

# utils.s
.include "constants.s"

# Global function
.globl print_string
print_string:

    call get_string_length
    mov %eax, %edx
    mov %rdi,       %rsi
    mov $1,         %edi
    mov $SYS_WRITE, %eax
    syscall
    ret

# Local function (for now)
get_string_length:
    mov $0, %eax # string length goes in rax
  L1_get_string_length:
    cmp $0, (%rdi, %rax,)
    je L2_get_string_length
    inc %eax
    jmp L1_get_string_length
  L2_get_string_length:
    ret

# file.s
.include "constants.s"

.data
str:    .string "Hellllloooo"

.text
.globl _start
_start:
    mov $str,   %rdi
    call print_string
    mov $0, %edi
    mov $SYS_EXIT, %eax
    syscall

如果我的理解是正确的，那么：

  1. 在链接期间，需要使.globl其他目标文件可以访问函数。这两个目标文件都需要链接在一起，例如：ld file.o utils.o -o file.
  2. 可以使用 导入/包含定义或宏.include "filename"。这实际上是将包含文件的内容复制/粘贴到该指令所在的位置。我们不需要链接——或做任何额外的事情——该.include文件的声明。多个文件是否使用相同的包含语句有关系吗？
  3. 我可能遗漏的任何其他内容或关于导入、包含等的提示？是否.include采用标准的 unix 路径，例如我可以这样做：.include "../constants.s"或.include "/home/constants.s"？

标签： assemblyx86linkergnu-assembler

解决方案

以下是“从文件中导入常量”的四种可能方法。

1. 使用.include和=（仅使用气体）

常量.inc：

    ANSWER_TO_LIFE = 0x42

代码.s：

    .include "constants.inc"
    mov $ANSWER_TO_LIFE, %eax
    add $ANSWER_TO_LIFE, %ebx   # best encoding
    mov $(ANSWER_TO_LIFE+17), %ecx
    mov $(ANSWER_TO_LIFE*ANSWER_TO_LIFE), %edx

建造：

as -o code.o code.s         # or gcc -c code.s
ld -o prog code.o code2.o   # or gcc -o prog code.o code2.o

这是仅使用 GNU 汇编器本身的特性的最直接的方法。我已经命名了包含文件.inc，而不是.s表明它是要包含到其他程序集源文件中，但不是自己组装的（因为它会生成一个不包含任何内容的目标文件）。您可以根据需要将它包含到尽可能多的不同文件中以使用该常量，并且支持相对或绝对路径（.include ../include/constants.inc两者.include /usr/share/include/constants.inc都可以）。

由于汇编器知道常量的值，它可以选择最好的指令编码。例如，x86add $imm, %reg32 指令有两种可能的编码：带有 32 位立即操作数（操作码 0x81）的 6 字节编码，以及带有 8 位符号扩展立即操作数（操作码 0x83）的较小的 3 字节编码。由于 0x42 适合 8 位，后者在这里可用，因此add $0x42, %ebx可以用三个字节编码为83 c3 42. 该示例还表明，我们可以在汇编时对常量执行任意算术运算。

2. 使用 C 预处理器（在实践中最常见）

常量.h：

#define ANSWER_TO_LIFE 0x42

代码.S:

#include "constants.h"
    mov $ANSWER_TO_LIFE, %eax
    add $ANSWER_TO_LIFE, %ebx   # also gets best encoding
    mov $(ANSWER_TO_LIFE*ANSWER_TO_LIFE), %ecx

建造：

gcc -c code.S              # can't use as by itself here
ld -o prog code.o code2.o  # or gcc if you prefer

cpp在这种方法中，您在将源文件提供给汇编程序之前对源文件运行 C 预处理器。如果您使用（注意区分大小写）命名源文件，该gcc命令将为您执行此操作。.S然后 C 风格#include和#define指令被扩展，因此汇编器只看到mov $0x42, %eax没有任何迹象表明该常量曾经有过名称。

这种方法的优点是该文件constants.h同样可以很好地包含在 C 代码中，这在您的项目混合 C 和汇编源代码的非常常见的情况下很有帮助。因此，这是我“在野外”最常看到的方法。（实际上，现实生活中的程序都不是完全用汇编语言编写的。）

在您的原始用例中，所讨论的常量是 Linux 系统调用号，这种方法是最好的，因为相关的包含文件已经由内核开发人员编写，您可以使用#include <asm/unistd.h>. 该文件定义了所有具有格式宏名称的系统调用号__NR_exit。

3.作为链接时解析的符号（有点尴尬）

常量.s：

    .global ANSWER_TO_LIFE
    ANSWER_TO_LIFE = 0x42

代码.s：

    mov $ANSWER_TO_LIFE, %eax
    add $ANSWER_TO_LIFE, %ebx   # not the optimal encoding
    mov $(ANSWER_TO_LIFE+17), %ecx
    #mov $(ANSWER_TO_LIFE*ANSWER_TO_LIFE), %ecx # error

建造：

as -o constants.o constants.s          # or gcc -c constants.s
as -o code.o code.s                    # etc
ld -o prog constants.o code.o code2.o  # or gcc

这是@fuz 在评论中提到的方法。它将符号视为ANSWER_TO_LIFE恰好位于绝对地址的标签0x42。汇编器将其视为任何其他标签；它在组装时不知道它的地址，因此它将它作为目标文件中的未解析引用保留code.o，链接器最终将解析它。

我可以看到这种方法的唯一真正好处是，如果我们想更改常量的值，比如 0x43，我们不必在所有源文件上重新运行汇编程序code.s code2.s ...；我们只需要重新组装constant.s和重新链接。所以我们节省了一点构建时间，但并不多，因为汇编代码通常非常快。（如果我们从 C 或 C++ 代码中引用符号可能会有所不同，因为编译速度较慢，但​​请参见下文。）

但也有一些明显的缺点：

  • 由于汇编器不知道常量的值，它必须假设它可能是对使用它的每条指令有效的最大大小。特别是在 中add $ANSWER_TO_LIFE, %ebx，它不能假设 8 位 0x83 编码将可用，所以它必须选择更大的 32 位编码。所以指令add $ANSWER_TO_LIFE, %ebx必须被汇编为81 c3 00 00 00 00，其中00 00 00 00被链接器替换为正确的值42 00 00 00。但是我们最终在一条指令上使用了 6 个字节，而理想情况下本可以使用 3 个字节进行编码。

  • 另一方面，mov64 位寄存器的立即数也有两种编码：一种采用符号扩展的 32 位立即数mov $imm32, %reg64（操作码 c7 带有 REX.W 前缀），它是 7 个字节，另一种采用完整的 64 -bit 立即mov $imm64, %reg64数（操作码 b8-b4 和 REX.W），即 10 个字节。汇编器默认选择 32 位格式，因为 64 位格式真的很长而且很少需要。但如果事实证明您的符号的值不适合 32 位，您将在链接时收到错误（“重定位被截断以适合”），您将不得不返回并强制 64使用助记符进行位编码movabs。如果您使用了方法 1 或 2，那么汇编程序将知道您的常量的值，并且会首先选择适当的编码。

  • 如果我们想对常量进行构建时算术，我们受限于可以在目标文件中表示为重定位的任何算术。恒定偏移有效，所以mov $(ANSWER_TO_LIFE+17), %ecx没关系；目标文件告诉链接器用符号的值加上常数 17 填充相关字节ANSWER_TO_LIFE。（对于实际的标签，你会想要这样的东西，比如从 static 访问一个成员struct。）但是更一般的操作，比如乘法不支持，因为人们通常不希望在地址上执行这些操作，因此mov $(ANSWER_TO_LIFE*ANSWER_TO_LIFE), %edx会导致汇编程序出错。如果我们需要生活答案的平方，我们必须编写一条mul指令来在运行时计算它，如果这是频繁调用且需要快速的代码，这将没有乐趣。

常量也可以从链接到我们项目的 C 代码中访问，但它必须被视为标签（变量的地址），这使它看起来很奇怪。我们必须写一些类似的东西

extern void *ANSWER_TO_LIFE;
printf("The answer is %lu\n", (unsigned long)&ANSWER_TO_LIFE);

如果我们尝试写一些更自然的东西

extern unsigned long ANSWER_TO_LIFE;
printf("The answer is %lu\n", ANSWER_TO_LIFE);

程序将尝试从内存地址 0x42 获取值，这将崩溃。

（此外，即使在第一个示例中，编译器输出的汇编输出也使用mov助记符，这再次导致汇编器选择 32 位移动。如果ANSWER_TO_LIFE大于2^32则链接将失败，这一次修复起来并不容易。 AFAIK，您需要给 gcc 一个适当的选项来告诉它更改其代码模型，这将导致每个地址加载都使用效率较低的 64 位形式，并且您必须为整个程序执行此操作。）

4. 作为存储在内存中并在运行时获取的值（低效）

常量.s：

    .section .rodata
    .global answer_to_life
answer_to_life:
    .int 0x42

代码.s：

    mov answer_to_life, %eax
    add answer_to_life, %ebx

    # mov answer_to_life+17, %ecx # not valid, no such instruction exists
    mov answer_to_life, %ecx
    add $17, %ecx   # needs two instructions

    # mov answer_to_life*answer_to_life, %edx # not valid
    mov answer_to_life, %eax
    mul %eax  # clobbers %edx

建造：

as -o constants.o constants.s
as -o code.o code.s
ld -o prog constants.o code.o code2.o

这种方法相当于const int answer_to_life = 42;在 C 程序中使用（尽管 C++ 不同）。值 42 存储在我们程序的内存中，当我们需要访问它时，我们需要一条从内存中读取的指令；我们不能再在每条指令中将其编码为立即数。这通常会执行较慢。如果我们需要对其进行任何算术运算，我们必须编写代码将其加载到寄存器中并在运行时执行适当的指令，这需要周期和代码空间。

我已将此处的名称更改为小写以匹配位于内存中的变量的约定，而不是不再是“编译时”常量。还要注意说明中的不同语法；mov answer_to_life, %eax，没有$符号，是从内存中加载而不是立即移动。 $answer_to_life在此示例中，您改为提供变量的地址（巧合的是0x402000，在我的测试程序中）。如果您希望能够构建与位置无关的可执行文件，这是现代 Linux 程序的标准，您需要改为编写answer_to_life(%rip)。

由于上述原因，这种方法对于在编译时真正已知的数字常量并不理想，但我将其包括在内是为了完整性，因为您在评论中询问过它。

推荐阅读