Idea: dyld has a "magic" function (lldb_image_notifier) which LLDB uses to get notified when new images are loaded (by setting a bp on the func). can we retry pid{}:... probes whenever we hit this BP?
NOTE: that func name is not guaranteed to be stable as far as i can tell; a pointer to the func is set in the image info struct which is then read out by lldb.
ideally we could use an actual breakpoint to hook lldb_image_notifier, however 1) that's very tangential to the rest of the project and 2) i think dyld can relocate itself which complicates things. for now just ~ab~use dtrace even more and let it manage symbol resolution. pid{}:dyld:lldb_image_notifier:entry {} seems to work even on a fresh process.
Interposing on libsystem_kernel.dylib seems like the easiest thing here. It's exposed there as libc is the main contract for API stability vs. the kernel.
mach_absolute_time
trap is handled separately https://github.com/apple-oss-distributions/xnu/blob/5c2921b07a2480ab43ec66f5b9e41cb872bc554f/osfmk/arm64/sleh.c#L1659 will probably need to do dylib injection and cross our fingerslibsystem_kernel.dylib
lldb_image_notifier
) which LLDB uses to get notified when new images are loaded (by setting a bp on the func). can we retrypid{}:...
probes whenever we hit this BP?ideally we could use an actual breakpoint to hook
lldb_image_notifier
, however 1) that's very tangential to the rest of the project and 2) i think dyld can relocate itself which complicates things. for now just ~ab~use dtrace even more and let it manage symbol resolution.pid{}:dyld:lldb_image_notifier:entry {}
seems to work even on a fresh process.