到底什么是“objc_msgSend_fixup”？

我正在摆弄 Objective-C 运行时，尝试编译 Objective-C 代码而不将其链接到libobjc，并且我的程序遇到了一些分段错误问题，因此我从中生成了一个汇编文件。我认为没有必要显示整个汇编文件。在我的某个时刻main函数，我有以下行（顺便说一句，这是我收到段错误之后的行）：

callq   *l_objc_msgSend_fixup_alloc

这是定义l_objc_msgSend_fixup_alloc:

.hidden l_objc_msgSend_fixup_alloc # @"\01l_objc_msgSend_fixup_alloc"
    .type   l_objc_msgSend_fixup_alloc,@object
    .section    "__DATA, __objc_msgrefs, coalesced","aw",@progbits
    .weak   l_objc_msgSend_fixup_alloc
    .align  16
l_objc_msgSend_fixup_alloc:
    .quad   objc_msgSend_fixup
    .quad   L_OBJC_METH_VAR_NAME_
    .size   l_objc_msgSend_fixup_alloc, 16

我已经重新实现了objc_msgSend_fixup作为一个函数（id objc_msgSend_fixup(id self, SEL op, ...)）返回nil（只是为了看看会发生什么），但是这个函数甚至没有被调用（程序在调用它之前崩溃了）。

所以，我的问题是，什么是callq *l_objc_msgSend_fixup_alloc应该做什么以及什么是objc_msgSend_fixup (after l_objc_msgSend_fixup_alloc:) 应该是（函数或对象）？

Edit

为了更好地解释，我没有将我的源文件链接到 objc 库。我想做的是实现库的某些部分，只是为了看看它是如何工作的。这是我所做的一种方法：

#include <stdio.h>
#include <objc/runtime.h>

@interface MyClass {

}
+(id) alloc;
@end

@implementation MyClass
+(id) alloc {
  // alloc the object
  return nil;
}
@end

id objc_msgSend_fixup(id self, SEL op, ...) {
  printf("Calling objc_msgSend_fixup()...\n");

  // looks for the method implementation for SEL in self's method list

  return nil;   // Since this is just a test, this function doesn't need to do that
}

int main(int argc, char *argv[]) {
    MyClass *m;
    m = [MyClass alloc];    // At this point, according to the assembly code generated
    // objc_msgSend_fixup should be called. So, the program should, at least, print
    // "Calling objc_msgSend_fixup()..." on the screen, but it crashes before
    // objc_msgSend_fixup() is called...

    return 0;
}

如果运行时需要访问对象的 vtable 或对象类的方法列表以找到要调用的正确方法，那么实际执行此操作的函数是什么？我觉得是这样的objc_msgSend_fixup， 在这种情况下。所以，当objc_msgSend_fixup被调用时，它接收一个对象作为其参数之一，如果该对象尚未初始化，则该函数将失败。

所以，我实现了我自己的版本objc_msgSend_fixup。根据上面的汇编源码，应该是可以调用的。该函数是否实际上正在寻找作为参数传递的选择器的实现并不重要。我只是想objc_msgSend_lookup被称为。但是，它没有被调用，也就是说，查找对象数据的函数甚至没有被调用，而不是被调用并导致错误（因为它返回一个nil（顺便说一句，这并不重要））。程序段之前失败objc_msgSend_lookup叫做...

Edit 2

更完整的组装片段：

.globl  main
    .align  16, 0x90
    .type   main,@function
main:                                   # @main
.Ltmp20:
    .cfi_startproc
# BB#0:
    pushq   %rbp
.Ltmp21:
    .cfi_def_cfa_offset 16
.Ltmp22:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
.Ltmp23:
    .cfi_def_cfa_register %rbp
    subq    $32, %rsp
    movl    $0, %eax
    leaq    l_objc_msgSend_fixup_alloc, %rcx
    movl    $0, -4(%rbp)
    movl    %edi, -8(%rbp)
    movq    %rsi, -16(%rbp)
    movq    L_OBJC_CLASSLIST_REFERENCES_$_, %rsi
    movq    %rsi, %rdi
    movq    %rcx, %rsi
    movl    %eax, -28(%rbp)         # 4-byte Spill
    callq   *l_objc_msgSend_fixup_alloc
    movq    %rax, -24(%rbp)
    movl    -28(%rbp), %eax         # 4-byte Reload
    addq    $32, %rsp
    popq    %rbp
    ret

For l_objc_msgSend_fixup_alloc， 我们有：

.hidden l_objc_msgSend_fixup_alloc # @"\01l_objc_msgSend_fixup_alloc"
    .type   l_objc_msgSend_fixup_alloc,@object
    .section    "__DATA, __objc_msgrefs, coalesced","aw",@progbits
    .weak   l_objc_msgSend_fixup_alloc
    .align  16
l_objc_msgSend_fixup_alloc:
    .quad   objc_msgSend_fixup
    .quad   L_OBJC_METH_VAR_NAME_
    .size   l_objc_msgSend_fixup_alloc, 16

For L_OBJC_CLASSLIST_REFERENCES_$_:

.type   L_OBJC_CLASSLIST_REFERENCES_$_,@object # @"\01L_OBJC_CLASSLIST_REFERENCES_$_"
    .section    "__DATA, __objc_classrefs, regular, no_dead_strip","aw",@progbits
    .align  8
L_OBJC_CLASSLIST_REFERENCES_$_:
    .quad   OBJC_CLASS_$_MyClass
    .size   L_OBJC_CLASSLIST_REFERENCES_$_, 8

OBJC_CLASS_$_MyClass是一个指向MyClass结构体定义，它也是由编译器生成的，并且也存在于汇编代码中。

要了解什么objc_msgSend_fixup它是什么以及它做什么 有必要确切地知道 Objective-C 中消息发送是如何执行的。所有 ObjC 程序员有一天都听说过编译器转换[obj message]语句进入objc_msgSend(obj, sel_registerName("message"))来电。然而，这并不完全准确。

为了更好地说明我的解释，请考虑以下 ObjC 片段：

[obj mesgA];
[obj mesgB];

[obj mesgA];
[obj mesgB];

在此片段中，两条消息发送至obj，每个发送两次。因此，您可能会想象生成以下代码：

objc_msgSend(obj, sel_registerName("mesgA"));
objc_msgSend(obj, sel_registerName("mesgB"));
objc_msgSend(obj, sel_registerName("mesgA"));
objc_msgSend(obj, sel_registerName("mesgB"));

However sel_registerName可能成本太高，并且在调用特定方法时调用它并不是明智之举。然后，编译器为每条要发送的消息生成如下结构：

typedef struct message_ref {
    id (*trampoline) (id obj, struct message_ref *ref, ...);
    union {
        const char *str;
        SEL sel;
    };
} message_ref;

因此，在上面的示例中，当程序启动时，我们会看到如下内容：

message_ref l_objc_msgSend_fixup_mesgA = { &objc_msgSend_fixup, "mesgA" };
message_ref l_objc_msgSend_fixup_mesgB = { &objc_msgSend_fixup, "mesgB" };

当这些消息需要发送到obj，编译器生成等效于以下内容的代码：

l_objc_msgSend_fixup_mesgA.trampoline(obj, &l_objc_msgSend_fixup_mesgA, ...);   // [obj mesgA];
l_objc_msgSend_fixup_mesgB.trampoline(obj, &l_objc_msgSend_fixup_mesgB, ...);   // [obj mesgB];

在程序启动时，消息引用蹦床是指向objc_msgSend_fixup功能。对于每个message_ref，当其trampoline第一次调用指针，objc_msgSend_fixup被称为接收obj消息必须发送到的地方message_ref它被称为的结构。所以呢objc_msgSend_fixup必须做的是获取要调用的消息的选择器。因为，对于每个消息引用只需执行一次，objc_msgSend_fixup还必须更换trampolineref 的字段通过指向另一个不修复消息选择器的函数的指针。这个函数称为objc_msgSend_fixedup（选择器已修复）。现在消息选择器已设置，无需再次执行此操作，objc_msgSend_fixup只是打电话objc_msgSend_fixedup这只是调用objc_msgSend。之后，如果消息引用trampoline再次被调用，它的选择器已经固定，并且objc_msgSend_fixedup是被调用的那个。

简而言之，我们可以写objc_msgSend_fixup and objc_msgSend_fixedup像这样：

id objc_msgSend_fixup(id obj, struct message_ref *ref, ...) {
    ref->sel = sel_registerName(ref->str);
    ref->trampoline = &objc_msgSend_fixedup;
    objc_msgSend_fixedup(obj, ref, ...);
}

id objc_msgSend_fixedup(id obj, struct message_ref *ref, ...) {
    objc_msgSend(obj, ref->sel, ...);
}

这使得消息发送速度更快，因为只有在第一次调用消息时才会发现适当的选择器（通过objc_msgSend_fixup）。在以后的调用中，选择器将已经被找到，并且消息被直接调用objc_msgSend (by objc_msgSend_fixedup).

在问题的汇编代码中，l_objc_msgSend_fixup_alloc is the alloc方法message_ref结构和分段错误可能是由其第一个字段中的问题引起的（也许它没有指向objc_msgSend_fixup...)