search for: mach_overrid

Folks, I just upgraded my Mac to Mountain Lion and on running R.app I get the following message: mach_override: some instructions unknown! Need to update mach_override.c err = f8000001 /Volumes/Haxdisk/Projects/DefaultFolderX/DFCarbonPatch/../../Libraries/mach_star-1.2-intel-0.3/mach_override/mach_override.c:215 err = f8000001 /Volumes/Haxdisk/Projects/DefaultFolderX/DFCarbonPatch/../../Libraries/mach_star...

In testing build patches for gcc 4.8 to allow darwin to have asan support, I ran across a defect in mach_override/mach_override.c... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 which was solved with the patch proposed by Alexander Potapenko in... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c29 Index: mach_override.c =================================================================== --- ma...

...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 var is missing the app is >> just re-execed. >> Dylib interposition is su...

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

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > 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 > > Kostya, > Unless I am misunderstanding the code in > asan/asan_intercepted_functions.h, > u...

...Kostya Serebryany wrote: > +kremenek, ganna > > On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > > > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > > 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 > > > > Kostya, > > Unless I am misunderstanding the code in > > a...

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > 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 Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h, using MAC_INTERPOSE_FUNCTIONS on FSF gcc wil...

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > 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 Kostya, Is the native function interposition that is being adopted based on... https://github.com/rentzsch/mach_inject ? I ass...

...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 var is missing the app is > >> just re-execed. > >>...

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

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

...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 var is missing the app is >> >> just re-execed...

...465e8 <_ZN10__cxxabiv120__unexpected_handlerE> 0x0020c49ba5d916e7 <__cxa_throw+7>: push %rbx 0x0020c49ba5d916e8 <__cxa_throw+8>: lea -0x20(%rdi),%rbx If we move the relative LEA instruction somewhere, we must fix the constant in order to keep it pointing to the same address. mach_override already does this for relative CALL and JMP instructions, but not for LEA. This should be fairly simple to fix. Note that the 32-bit variant crashes on another invalid address: ASAN:SIGSEGV ================================================================= ==89768== ERROR: AddressSanitizer: SEGV...

...gt; <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 var is missing the app is > >> &gt...

Hi all, I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran into a problem. In the past we used mach_override and the dynamic_cast source to override the built-in dynamic_cast operator to detect shared library issues (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a duplicated RTTI is found, giving us a chance to backtrace the offending class. I'm looking for a better sol...

Hi Akos, you should send this to the clang mailing list instead. Ciao, Duncan. > I'm trying to convert our code base from GCC 4.0 to LLVM (on mac OS X), and ran > into a problem. In the past we used mach_override and the dynamic_cast source to > override the built-in dynamic_cast operator to detect shared library issues > (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a > duplicated RTTI is found, giving us a chance to backtrace the offending class. > > I'm...

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_th...

...ls as well) http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/sysinfo.cc - Yet another piece of third-party code (mit license) is used for Apple-specific work (function overriding). Same question as above apply. http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/mach_override.c - test-specific: can I rely on gtest being installed? (fresh version is required). Thanks, --kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111116/ad18f82f/attachment.html>

...s-sanitizer/source/browse/trunk/asan/sysinfo.cc > > - Yet another piece of third-party code (mit license) is used for > > Apple-specific work (function overriding). Same question as above apply. > > > > > http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/mach_override.c > > - test-specific: can I rely on gtest being installed? (fresh version is > > required). > > Compiler-rt doesn't currently have a very good test set up. You'll > probably have to find a way to shoehorn this in for your own testing > initially, but we can try and...

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >