Injecting Missing Methods at Runtime
The important thing here is that most of the methods you’ll use are lazily bound. It means that instead of resolving the address of every method at loading time, the linker will write the address of a resolution method, and the effective resolution will be made the first time the method is used.
[…]
So, if a symbol is missing, how about resolving it by ourselves?
This is simpler than it sounds, and here is how we’ll proceed: we’ll parse the Mach-O header of the library, find where the lazy binding information is stored, find the symbol table, and replace the pointer in the __la_symbols_ptr section with our replacement code.
2 Comments RSS · Twitter
I think this method is already obsolete. I can't remember where I read that (probably in some WWDC slides), but the stubs and late binding machinery on macOS is a thing from the past. It was used for optimization and to avoid having to bind all symbols at launch time. With the new dyld, as the binding is executed only once and the result cached, the need for stubs is far more significant.
Got it. This is in the "App Startup Time: Past, Present, and Future". They explain that dyld3 do "eager symbol resolution" which replace resolution at first call.
