similar to: mach_override.c

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

+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some issues with the allocator which

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

On Sat, Dec 01, 2012 at 05:42:15PM +0400, 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

On Tue, Dec 04, 2012 at 09:46:09AM -0800, Alexander Potapenko wrote: > +kledzik at apple.com > The dynamic runtime is using dylib interposition (google for > "__DATA,__interpose). > If I'm understanding correctly (Nick, can you please confirm this?) > this allows to interpose the function regardless of the two-level > namespace. > The support for dynamic runtime in

+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

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

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

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

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,

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

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start

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

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

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

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_throw () 2: x/i $pc 0x100016386

Hi Daniel, Chris suggested to talk to you about committing the AddressSanitizer (asan) run-time into the llvm tree (llvm-project/compiler-rt). Questions: - What is the preferred name for the directory? (asan? libasan? address_sanitizer? AdressSanitizer?) - Should the asan run-time use cmake, or just make, or what? The build is a bit tricky, especially for tests. We currently use make. - How

On Thu, Nov 24, 2011 at 7:27 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Quick answers, I'm on txgiving break this week and not doing any real > work, but I will be doing more compiler-rt work when I get back > (initially focused at getting profile libs to come from compiler-rt on > Linux et al). > > On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <kcc at

Quick answers, I'm on txgiving break this week and not doing any real work, but I will be doing more compiler-rt work when I get back (initially focused at getting profile libs to come from compiler-rt on Linux et al). On Wed, Nov 16, 2011 at 9:24 PM, Kostya Serebryany <kcc at google.com> wrote: > Hi Daniel, > Chris suggested to talk to you about committing the AddressSanitizer

On Mon, Nov 28, 2011 at 1:15 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Nov 24, 2011 at 7:27 AM, Daniel Dunbar <daniel at zuster.org> wrote: >> >> Quick answers, I'm on txgiving break this week and not doing any real >> work, but I will be doing more compiler-rt work when I get back >> (initially focused at getting profile libs