Table of Contents
- objc_msgSend() Tour Part 1: The Road Map
- objc_msgSend() Tour Part 2: Setting the Stage
- objc_msgSend() Tour Part 3: The Fast Path
- objc_msgSend() Tour Part 4: Method Lookup & Some Odds and Ends
In any case, with the foundation set — with the id of the object to be targeted in
%rdi and the selector of the method to be invoked in
%rsi — we can jump into
objc_msgSend() and understand exactly what happens instruction by instruction. Or more specifically, the compiler issues a
objc_msgSend() (which sets up a stackframe for
objc_msgSend() which, through tail call optimization, turns into the stackframe for the called method) and the method implementation that
objc_msgSend() jumps to will issue a
ret instruction to unwind the stack back to the original caller’s frame.
It is pretty easy to correlate the disassembly with the comments and code in the original source file. However, if you ever need to step through the messenger (
si steps by instruction in gdb), this will be easier to follow as this is closer to the reality during a debug session.
For almost all method dispatches, dispatch takes what is called the “fast path”. That is,
objc_msgSend() finds the implementation in the method cache and passes control to the implementation. Since this is the most common path, it is a good opportunity to break the tour of
objc_msgSend() into two parts; the fast path and the slow path (with administrivia).