GAS ELF 什么时候需要指令 .type、.thumb、.size 和 .section？

Question

我正在为基于 ARM Cortex-M3 的微控制器（Thumb 2 指令集）开发一个汇编程序，使用 GNU as。

在一些示例代码中，我发现诸如 .size、.section 和 .type 之类的指令，我认为它们是 ELF 指令。举个例子：

    .section    .text.Reset_Handler
    .weak       Reset_Handler
    .type       Reset_Handler, %function  
Reset_Handler:
    bl      main
    b       Infinite_Loop    
    .size   Reset_Handler, .-Reset_Handler

---

.type 指令据说可以设置符号的类型 - 通常为 %object （意味着数据？）或 %function.我不知道这有什么区别。它并不总是包含在内，所以我不确定何时需要使用它。

与此相关的还有 .thumb_func 指令。根据我的阅读，它似乎可能相当于：

.thumb 
.type Symbol_Name, %function

或者它是完全不同的东西？

---

.size 据称设置与符号关联的大小。什么时候需要这个，我不知道。这是默认计算的，但可以用该指令覆盖吗？如果是这样 - 你什么时候想覆盖？

---

.section 更容易找到文档，我想我对它的作用有一个很好的了解，但我仍然有点不确定其用法。按照我的理解，它在不同的 ELF 部分之间切换（text 用于代码，data 用于可写数据，bss 用于未初始化数据，>rodata 用于常量和其他），并在需要时定义新的。我猜你会根据是否定义代码、数据、未初始化数据等在这些之间进行切换。但是为什么要为函数创建一个小节，如上面的示例所示？

---

Any help with this is appreciated. If you can find links to tutorials or docs that explain this in greater detail - preferably understandable for a novice - I would be very grateful.

到目前为止，用作手册已经提供了一些帮助 - 也许您可以从中获得更多信息比我有更多的知识。

Answer 1

多年来，我一直在使用大量汇编程序对arm/thumb进行编程，并且只需要很少的指令。

正如另一位响应者指出的那样， .thumb_func 非常重要。

例如

.globl _start
_start:
    b   reset

reset:

.arm

.globl one
one:
    add r0,r0,#1
    bx lr

.thumb

.globl two
two:
    add r0,r0,#2
    bx lr

.thumb_func
.globl three
three:
    add r0,r0,#3
    bx lr


.word two
.word three

.arm 或曾经是 .code32 或 .code 32 告诉它这是arm代码而不是thumb代码，这对于你来说cortex-m3 你不需要使用。

.thumb 同样，曾经是 .code 16 或者也许仍然有效，同样的处理使得以下代码拇指不是手臂。

如果您使用的标签不是需要从其他文件或间接​​分支到的全局标签，则不需要 .thumb_func。但是为了正确计算这些全局标签之一的分支地址（lsbit 为 1 代表拇指，0 代表手臂），您需要将其标记为拇指或手臂标签，并且thumb_func 会执行此操作，否则您必须在分支添加更多代码之前设置该位，并且该标签无法从 C 调用。

00000000 <_start>:
   0:   eaffffff    b   4 <one>

00000004 <one>:
   4:   e2800001    add r0, r0, #1
   8:   e12fff1e    bx  lr

0000000c <two>:
   c:   3002        adds    r0, #2
   e:   4770        bx  lr

00000010 <three>:
  10:   3003        adds    r0, #3
  12:   4770        bx  lr
  14:   0000000c    andeq   r0, r0, ip
  18:   00000011    andeq   r0, r0, r1, lsl r0

直到 .thumb 汇编程序都是所需的 Arm 代码。

根据需要，两个和三个标签/功能都是拇指代码，但是两个标签具有偶数编号地址，而三个标签/功能具有正确的奇数编号地址。

使用最新的代码源工具来组装、链接和转储上述示例。

现在对于 cortex-m3，一切都是拇指（/thumb2）.thumb_func 可能并不那么重要，它可能只适用于命令行开关（很容易做一个实验来找出答案）。不过，如果您从仅限拇指的处理器转向普通的手臂/拇指核心，这是一个好习惯。

汇编器通常喜欢添加所有这些指令和其他方式，使事物看起来/感觉更像高级语言。我只是说你不必使用它们，我为arm切换了汇编器，并为许多不同的处理器使用了许多不同的汇编器，并且更喜欢少即是多的方法，这意味着专注于汇编本身并使用尽可能少的工具特定项目。不过，我通常是例外而不是规则，因此您可以通过查看编译器输出生成的指令（并使用文档进行验证）来找出更常用的指令。

unsigned int one ( unsigned int x )
{
    return(x+1);
}


    .arch armv5te
    .fpu softvfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 2
    .eabi_attribute 30, 2
    .eabi_attribute 18, 4
    .file   "bob.c"
    .text
    .align  2
    .global one
    .type   one, %function
one:
    .fnstart
.LFB0:
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    add r0, r0, #1
    bx  lr
    .fnend
    .size   one, .-one
    .ident  "GCC: (Sourcery G++ Lite 2010.09-50) 4.5.1"
    .section    .note.GNU-stack,"",%progbits

当将arm和thumb汇编器或数据与汇编器混合时，我确实使用.align，您会期望此类平台的汇编器知道一些显而易见的事情，例如thumb指令位于半字边界上，而arm指令位于半字边界上。在单词边界上对齐。这些工具并不总是那么智能。洒上 .align 不会有什么坏处。

.text 是默认值，因此有点多余，但不会造成伤害。 .text 和 .data 是标准属性（不是特定于arm的），如果你正在编译你可能关心的目标上的rom和ram的组合（取决于你的目标）与你的链接器脚本一起做），否则 .text 将适用于所有内容。

.size 显然是该指令的函数开始的大小。汇编器无法自行解决这一问题，因此，如果此函数的大小对于您的代码、链接器脚本、调试器、加载器等很重要，那么这需要正确，否则您不必费心。无论如何，函数是一个高级概念，汇编器实际上并不具有函数，更不需要声明其大小。 C 编译器当然不在乎，它只是寻找要分支到的标签，对于 ARM 系列来说，它是分支到的拇指代码还是 ARM 代码。

如果您在大段代码上懒惰使用立即数 (ldr rx,=0x12345678)，您可能会发现 .pool 指令（有一个较新的等效项）很有用。同样，这些工具并不总是足够聪明，无法将这些数据放置在无条件分支之后，有时您必须告诉它们。我半认真地说懒惰，一直做标签：.word 的事情是很痛苦的，我相信arm和gcc工具都允许这个快捷方式，所以我和其他人一样使用它。

另请注意，llvm 会输出一个额外的 .eabi_attribute 或两个由 binutils 的代码源版本/mod 支持的附加 .eabi_attribute ，但 gnu 发布的 binutils 不支持（可能尚不支持）。两个有效的解决方案，修改 llvm 的 asm 打印函数以不写入 eabi_attributes 或至少使用注释 (@) 写入它们，或者从代码中获取 binutils 源/mods sourcery 并以这种方式构建 binutils。代码源倾向于引导 gnu（例如，thumb2 支持）或者向后移植新功能，因此我假设这些 llvm 属性不久就会出现在主线 binutils 中。通过从 llvm 编译的代码中删除 eabi_attribute，我没有遭受任何不良影响。

这是上面相同函数的 llvm 输出，显然这是我修改以注释掉 eabi_attribute 的 llc。

    .syntax unified
@   .eabi_attribute 20, 1
@   .eabi_attribute 21, 1
@   .eabi_attribute 23, 3
@   .eabi_attribute 24, 1
@   .eabi_attribute 25, 1
@   .eabi_attribute 44, 1
    .file   "bob.bc"
    .text
    .globl  one
    .align  2
    .type   one,%function
one:                                    @ @one
@ BB#0:                                 @ %entry
    add r0, r0, #1
    bx  lr
.Ltmp0:
    .size   one, .Ltmp0-one

elf 文件格式有详细的文档记录，如果您想真正了解 elf 特定指令（如果有）正在做什么，则非常容易解析。其中许多指令对链接器的帮助最为重要。例如，.thumb_func、.text、.data。

Answer 2

程序的各个部分与大多数系统（Linux、BSD...）存储其对象和可执行文件的 ELF 格式密切相关。 这篇文章应该能让您深入了解ELF 是如何工作的，这将帮助您理解节的原因。

简而言之，节可以让您将程序组织到具有不同属性的不同内存区域，包括地址、执行和写入权限等。在最终链接阶段，链接器使用特定的 链接器脚本，通常将同名的所有部分分组在一起（例如，来自所有编译单元的所有代码在一起，... ）并为它们分配内存中的最终地址。

对于嵌入式系统，它们的用途尤其明显：首先，引导代码（通常包含在 .text 部分中）必须加载到固定地址才能执行。然后，只读数据可以被分组到专用的只读部分中，该部分将被映射到设备的 ROM 区域中。最后一个例子：操作系统的初始化函数只被调用一次，之后就不再使用，浪费了宝贵的内存空间。如果所有这些初始化函数都被分组到一个名为 .initcode 的专用部分，并且如果该部分被设置为程序的最后一部分，那么操作系统可以轻松回收该内存一旦初始化完成，就降低自己的内存上限。例如，Linux 就使用该技巧，GCC 允许您通过在后缀 __attribute__ ((section ("MYSECTION")))

后缀来将变量或方法放入特定部分。 type 和 .size 实际上对我来说仍然很不清楚。我将它们视为链接器的助手，并且从未在汇编器生成的代码之外看到它们。

.thumb_func 似乎只需要旧的 OABI 接口才能与 Arm 代码互通。除非您使用旧的工具链，否则您可能不必担心它。

Answer 3

我在试图弄清楚为什么 ARM 和 Thumb 互操作与最近的 binutils 发生冲突时遇到了这个问题（已通过 2.21.53 (MacPorts) 和 2.22 (Yagarto 4.7.1) 验证）。

根据我的经验，.thumb_func 与早期的 binutils 配合得很好，可以生成正确的互操作胶合板。然而，随着最新版本的发布，
需要 .type *name*, %function 指令来确保正确生成单板。

binutils 邮件列表帖子

我懒得去挖掘旧版本的 binutils，用于检查 .type 指令是否足以替代早期 binutils 的 .thumb_func。我想在代码中包含这两个指令没有什么坏处。

编辑：更新了在代码中使用 .thumb_func 的注释，显然它适用于 ARM->Thumb 互操作来标记 Thumb 例程来生成胶合板，但 Thumb->ARM 互操作失败，除非 .type 指令用于标记 ARM 函数。