On Jan 23, 2017, at 6:25 PM, Junker, Gregory < email@hidden> wrote:
In lieu of that, the problem I am seeing is that we DYLD_INSERT_LIBRARIES (that successfully
employs the standard interposing attributes) a small shim into the target process, which checks
to see if another shim should be loaded. If so, that second shim is dlopen()'ed into the
process, but none of the interposed functions in that library are ever invoked. I need to figure
out why the second library's interposing doesn't work (hence the desire to debug through the
dyld library). If anyone with intimate knowledge of the dynamic loaded in MacOS can help, I'm
fine with not having to build the dyld library (but these build issues still should be sorted).
To clarify: 1. You have a process that defines and calls some functions F1() and F2(). 2. You have a library shim1.dylib that uses __DATA,__interpose to interpose F1(). 3. You have a second library shim2.dylib that uses __DATA,__interpose to interpose F2(). 4. You use DYLD_INSERT_LIBRARIES to load shim1.dylib. Its interposition of calls to F1() works. 5. You call dlopen() to load shim2.dylib. Its interposition of calls to F2() does not work.
This behavior is expected. An interposition using __DATA,__interpose only works when the original function definition and the interposed definition are loaded at the same time. In the arrangement above the interposition in shim2.dylib is too late. The original function was already loaded - at launch - so the interposition at dlopen time can't touch it.
There is a function dyld_dynamic_interpose() that may do what you want. It can rebind function call sites that have already been bound. It is less complete than __DATA,__interpose, however. If some other code has already run and saved a function pointer to the original definition then nothing in dyld can prevent the old implementation from being called through that function pointer.
--
|