为什么我不能在 ARM64 MacOS 的 .text 部分中组装绝对地址？答案

【问题标题】：Why can't I assemble absolute addresses in the .text section on ARM64 MacOS?为什么我不能在 ARM64 MacOS 的 .text 部分中组装绝对地址？
【发布时间】：2022-08-17 12:26:48
【问题描述】：

我在 ARM64 M1 Pro 笔记本电脑上使用 clang 13.1.6 和 MacOS Monterey 12.5 编写程序集。

如果我尝试在.text 部分中使用.dword/.xword 并将标签的地址作为其值，我的程序在启动时会以bus error 崩溃。

最小的可重现示例：

    .text
    .balign 4
    .global _main
_main:
    // accepted method to load from static address
    adrp x1, vector@GOTPAGE
    ldr x1, [x1, #vector@GOTPAGEOFF]
    // now x1 contains the address of vector
    ldr x2, [x1]
    // now x2 should contain the address of dest
    br x2
dest:
    mov x0, #0
    ret

vector: 
    .xword dest

这使用cc reloc.s -o reloc 组装和链接没有错误或警告，但在运行时立即出现总线错误，显然甚至在到达我的实际代码之前。来自lldb 的回溯如下：

* thread #1, stop reason = EXC_BAD_ACCESS (code=2, address=0x100003fb0)
    frame #0: 0x000000010001da54 dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 60
dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const:
->  0x10001da54 <+60>: str    x19, [x20]
    0x10001da58 <+64>: ldp    x29, x30, [sp, #0x20]
    0x10001da5c <+68>: ldp    x20, x19, [sp, #0x10]
    0x10001da60 <+72>: add    sp, sp, #0x30
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, stop reason = EXC_BAD_ACCESS (code=2, address=0x100003fb0)
  * frame #0: 0x000000010001da54 dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 60
    frame #1: 0x0000000100040fd4 dyld`invocation function for block in dyld3::MachOLoaded::fixupAllChainedFixups(Diagnostics&, dyld_chained_starts_in_image const*, unsigned long, dyld3::Array<void const*>, void (void*, void*) block_pointer) const + 424
    frame #2: 0x0000000100041080 dyld`dyld3::MachOLoaded::walkChain(Diagnostics&, dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, unsigned short, bool, unsigned int, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, bool&) block_pointer) const + 104
    frame #3: 0x00000001000412b0 dyld`dyld3::MachOLoaded::forEachFixupInSegmentChains(Diagnostics&, dyld_chained_starts_in_segment const*, bool, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, dyld_chained_starts_in_segment const*, bool&) block_pointer) const + 208
    frame #4: 0x0000000100040e04 dyld`dyld3::MachOLoaded::forEachFixupInAllChains(Diagnostics&, dyld_chained_starts_in_image const*, bool, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, dyld_chained_starts_in_segment const*, bool&) block_pointer) const + 96
    frame #5: 0x0000000100040d98 dyld`dyld3::MachOLoaded::fixupAllChainedFixups(Diagnostics&, dyld_chained_starts_in_image const*, unsigned long, dyld3::Array<void const*>, void (void*, void*) block_pointer) const + 120
    frame #6: 0x000000010001da0c dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 136
    frame #7: 0x000000010001d788 dyld`dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 204
    frame #8: 0x0000000100021574 dyld`dyld4::JustInTimeLoader::applyFixups(Diagnostics&, dyld4::RuntimeState&, dyld4::DyldCacheDataConstLazyScopedWriter&, bool) const + 604
    frame #9: 0x000000010000d904 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 1928
    frame #10: 0x000000010000d06c dyld`start + 488

崩溃似乎在动态链接器内部，根本不在我的代码中。

具有相同行为的更简单的示例是：

    .text
    .balign 4
    .global _main
_main:  
    ldr x1, =dest
    br x1
dest:   
    mov x0, #0
    ret

这里ldr x1, =dest 应该类似地将dest 的地址组装到文字池中（.text 部分中的附近位置）并从那里加载到x1。

等效代码在 ARM64 Linux 上运行良好。

为什么会这样，我该如何解决？

这是一个自我回答的问题，以分享一个非常混乱的经历的结果。

标签： macos assembly dynamic-linking arm64 relocation

【解决方案1】：

ARM64 MacOS 似乎不支持文本部分中的绝对地址。据我所知，动态链接器尝试应用重定位/修复将dest 的实际运行时地址存储到vector，但由于.text 已经被映射为只读而崩溃。

因此，如果您有一个对象需要使用标签或其他对象的地址进行初始化，那么您需要将它放在数据部分中，即使它是只读的。这就是 clang 在编译 C/C++ 代码时所做的。例如，如果你用 C 编写

const int i = 42;
const int * const ptr1 = &i;
const int * const ptr2 = NULL;
const int * const ptr3 = (const int *)0xdeadbeefcafed00dUL;

然后i, ptr2, ptr3 前面都有.section __TEXT,__const，但ptr1 前面有.section __DATA,__const。后一部分在运行时也是只读的，但显然在重定位完成时映射为读写。

而且您根本无法使用ldr x1, =label。如果label 在文本部分中，则酌情使用adr 或adrp / add 在x1 中生成地址，或者酌情从全局偏移表中加载它。

如果链接器能检测到这一点并警告你，而不是继续构建一个神秘崩溃的可执行文件，那就太好了。

【讨论】：