search for: dyld_insert_librari

...012 13:32, Alexander Potapenko <glider at google.com> wrote: >> No, we are not going to use mach_inject. This isn't portable and may >> be even harder to set up than mach_override. >> The new ASan runtime will use the dylib interposition and will in fact >> require DYLD_INSERT_LIBRARIES to work. However ASan already handles it >> correctly itself: if the corresponding env var is missing the app is >> just re-execed. >> Dylib interposition is supported by Apple and should work on iOS as >> well as Mac OS. It will also probably simplify hooking the memory &...

On 30 November 2012 13:32, Alexander Potapenko <glider at google.com> wrote: > No, we are not going to use mach_inject. This isn't portable and may > be even harder to set up than mach_override. > The new ASan runtime will use the dylib interposition and will in fact > require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > correctly itself: if the corresponding env var is missing the app is > just re-execed. > Dylib interposition is supported by Apple and should work on iOS as > well as Mac OS. It will also probably simplify hooking the memory > allocations...

...Potapenko <glider at google.com> wrote: > >> No, we are not going to use mach_inject. This isn't portable and may > >> be even harder to set up than mach_override. > >> The new ASan runtime will use the dylib interposition and will in fact > >> require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > >> correctly itself: if the corresponding env var is missing the app is > >> just re-execed. > >> Dylib interposition is supported by Apple and should work on iOS as > >> well as Mac OS. It will also probably simplify...

...lider at google.com> wrote: >> >> No, we are not going to use mach_inject. This isn't portable and may >> >> be even harder to set up than mach_override. >> >> The new ASan runtime will use the dylib interposition and will in fact >> >> require DYLD_INSERT_LIBRARIES to work. However ASan already handles it >> >> correctly itself: if the corresponding env var is missing the app is >> >> just re-execed. >> >> Dylib interposition is supported by Apple and should work on iOS as >> >> well as Mac OS. It will also pr...

...ull control of the address space (PAGE_ZERO control, overriding the shared cache mappings, etc) that is really the only supported mechanism. > The issue I am having with libSystem.dylib is the lack of weak linkage (versus weak_import) i.e. weak aliases. I don’t want to use a wrapper binary with DYLD_INSERT_LIBRARIES. I want to interpose Libc symbols with some of the symbols present in my binary (memory allocator, mmap). Interposition support is somewhat lacking in the Mach-O toolchain and runtime linker despite the Mach-O format technically supporting what I need (N_INDR and N_WEAK_DEF). > > - https:/...

...gt; wrote: > >> >> No, we are not going to use mach_inject. This isn't portable and may > >> >> be even harder to set up than mach_override. > >> >> The new ASan runtime will use the dylib interposition and will in fact > >> >> require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > >> >> correctly itself: if the corresponding env var is missing the app is > >> >> just re-execed. > >> >> Dylib interposition is supported by Apple and should work on iOS as > >> >> well as Mac...

No, we are not going to use mach_inject. This isn't portable and may be even harder to set up than mach_override. The new ASan runtime will use the dylib interposition and will in fact require DYLD_INSERT_LIBRARIES to work. However ASan already handles it correctly itself: if the corresponding env var is missing the app is just re-execed. Dylib interposition is supported by Apple and should work on iOS as well as Mac OS. It will also probably simplify hooking the memory allocations in ASan, which is now ver...

...n't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on... https://github.com/rentzsch/mach_inject ? I assume that any method used will be transparent to the user and not require manually setting DYLD_INSERT_LIBRARIES, correct? Jack > > On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > > > Looks like this happens on x86_64 because the position of __cxa_throw > > is too far from the allocated branch island (should be <2G). This can &gt...

> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working

Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from