Hooking C Functions at Runtime
thomasfinch.me
Hooking C Functions at Runtime
1–5 of 5 posts
Re: Hooking C Functions at Runtime
#2Interesting.. in the linux/unix world I've always intercepted functions with LD_PRELOAD. I'm guessing that's not an option on OS X?
Re: Hooking C Functions at Runtime
#3That's a lot of work for something that the dynamic linker on OS X supports out of the box. See, for example, http://toves.freeshell.org/interpose/ or search for "OS X interpose" on your favorite search engine.
Re: Hooking C Functions at Runtime
#4Interesting.. in the linux/unix world I've always intercepted functions with LD_PRELOAD. I'm guessing that's not an option on OS X?
DYLD_INSERT_LIBRARIES is more or less the OS X equivalent of LD_PRELOAD.
Re: Hooking C Functions at Runtime
#5Interesting.. in the linux/unix world I've always intercepted functions with LD_PRELOAD. I'm guessing that's not an option on OS X?
DYLD_INSERT_LIBRARIES is more or less the OS X equivalent of LD_PRELOAD.
With a big bias towards "less". Dynamic linking on OS X uses strong binding (unless you specifically link your binaries with the option that disables strong binding). That is, symbols are associated with libraries. So for example, when your program wants the symbol for e.g. malloc, the symbol table will also have the information that the symbol is in libSystem.dylib (or whatever the lib for that is), and the dynamic linker will pick malloc from there, even when DYLD_INSERT_LIBRARIES contains a library exporting the malloc symbol.
On GNU/Linux at least, even with symbol versioning, which adds some binding information linking symbol version names to library names, ld.so still resolves symbols with versions to the symbol exported by a library in LD_PRELOAD.