Messaging with the GNU Objective-C Runtime

This section is specific for the GNU Objective-C runtime. If you are using a different runtime, you can skip it.

The implementation of messaging in the GNU Objective-C runtime is designed to be portable, and so is based on standard C.

Sending a message in the GNU Objective-C runtime is composed of two separate steps. First, there is a call to the lookup function, objc_msg_lookup () (or, in the case of messages to super, objc_msg_lookup_super ()). This runtime function takes as argument the receiver and the selector of the method to be called; it returns the IMP, that is a pointer to the function implementing the method. The second step of method invocation consists of casting this pointer function to the appropriate function pointer type, and calling the function pointed to it with the right arguments.

For example, when the compiler encounters a method invocation such as [object init], it compiles it into a call to objc_msg_lookup (object, @selector(init)) followed by a cast of the returned value to the appropriate function pointer type, and then it calls it.

Dynamically Registering Methods

If objc_msg_lookup() does not find a suitable method implementation, because the receiver does not implement the required method, it tries to see if the class can dynamically register the method.

To do so, the runtime checks if the class of the receiver implements the method

+ (BOOL) resolveInstanceMethod: (SEL)selector;

in the case of an instance method, or

+ (BOOL) resolveClassMethod: (SEL)selector;

in the case of a class method. If the class implements it, the runtime invokes it, passing as argument the selector of the original method, and if it returns YES, the runtime tries the lookup again, which could now succeed if a matching method was added dynamically by +resolveInstanceMethod: or +resolveClassMethod:.

This allows classes to dynamically register methods (by adding them to the class using class_addMethod) when they are first called. To do so, a class should implement +resolveInstanceMethod: (or, depending on the case, +resolveClassMethod:) and have it recognize the selectors of methods that can be registered dynamically at runtime, register them, and return YES. It should return NO for methods that it does not dynamically registered at runtime.

If +resolveInstanceMethod: (or +resolveClassMethod:) is not implemented or returns NO, the runtime then tries the forwarding hook.

Support for +resolveInstanceMethod: and resolveClassMethod: was added to the GNU Objective-C runtime in GCC version 4.6.

Forwarding Hook

The GNU Objective-C runtime provides a hook, called __objc_msg_forward2, which is called by objc_msg_lookup() when it cannot find a method implementation in the runtime tables and after calling +resolveInstanceMethod: and +resolveClassMethod: has been attempted and did not succeed in dynamically registering the method.

To configure the hook, you set the global variable __objc_msg_forward2 to a function with the same argument and return types of objc_msg_lookup(). When objc_msg_lookup() cannot find a method implementation, it invokes the hook function you provided to get a method implementation to return. So, in practice __objc_msg_forward2 allows you to extend objc_msg_lookup() by adding some custom code that is called to do a further lookup when no standard method implementation can be found using the normal lookup.

This hook is generally reserved for ‘Foundation’ libraries such as GNUstep Base, which use it to implement their high-level method forwarding API, typically based around the forwardInvocation: method. So, unless you are implementing your own ‘Foundation’ library, you should not set this hook.

In a typical forwarding implementation, the __objc_msg_forward2 hook function determines the argument and return type of the method that is being looked up, and then creates a function that takes these arguments and has that return type, and returns it to the caller. Creating this function is non-trivial and is typically performed using a dedicated library such as libffi.

The forwarding method implementation thus created is returned by objc_msg_lookup() and is executed as if it was a normal method implementation. When the forwarding method implementation is called, it is usually expected to pack all arguments into some sort of object (typically, an NSInvocation in a ‘Foundation’ library), and hand it over to the programmer (forwardInvocation:) who is then allowed to manipulate the method invocation using a high-level API provided by the ‘Foundation’ library. For example, the programmer may want to examine the method invocation arguments and name and potentially change them before forwarding the method invocation to one or more local objects (performInvocation:) or even to remote objects (by using Distributed Objects or some other mechanism). When all this completes, the return value is passed back and must be returned correctly to the original caller.

Note that the GNU Objective-C runtime currently provides no support for method forwarding or method invocations other than the __objc_msg_forward2 hook.

If the forwarding hook does not exist or returns NULL, the runtime currently attempts forwarding using an older, deprecated API, and if that fails, it aborts the program. In future versions of the GNU Objective-C runtime, the runtime will immediately abort.