search for: mach_inject

...caused by a CoreFoundation dependency, which I'm trying to eliminate now. On Mon, Dec 3, 2012 at 8:50 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > 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...

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 t...

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-ex...

...p 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 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 beca...

...ld open an llvm bugzilla on those. Jack > > On Mon, Dec 3, 2012 at 8:50 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: > > 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 th...

...those. > Jack > >> >> On Mon, Dec 3, 2012 at 8:50 PM, Rafael Espíndola >> <rafael.espindola at gmail.com> wrote: >> > 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 >> >> correct...

...> > > >> > >> On Mon, Dec 3, 2012 at 8:50 PM, Rafael Espíndola > >> <rafael.espindola at gmail.com> wrote: > >> > 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 > >&...

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