search for: darwin_objdir

...l require the missing blocks support to be implemented. I did a quick and dirty attempt to build libasan using libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm svn. The bootstrap chokes on... /bin/sh ../libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/li...

...oice for us but to use the Apple-blessed mechanism. Do we want to support both? No, that's too expensive. And very likely once we move to function interposition, mach_override will rot very soon. > > /bin/sh ../libtool --tag=CXX --mode=compile > /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ > -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ > -nostdinc++ > -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 > -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-a...

...hment.cgi?id=28849 with the addition of the usage of -DMISSING_BLOCKS_SUPPORT and the appropriate tests on that to avoid the missing blocks support on FSF gcc. Jack > > > > > > /bin/sh ../libtool --tag=CXX --mode=compile > > /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ > > -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ > > -nostdinc++ > > -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0 > > -I/sw/src/fink.build/gcc48-4.8.0-1000/da...

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

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

...I see with -fsanitize=address in the FSF g++ testsuite typically appear as simple segfaults such as with... FAIL: g++.dg/abi/covariant3.C -std=c++98 execution test FAIL: g++.dg/abi/covariant3.C -std=c++11 execution test that backtraces as... Starting program: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/covariant3.exe Reading symbols for shared libraries +++++................................. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x000010002000068a 0x00000001000015d0 in c1::c1 (this=0x100003d08, __vtt_parm...

I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote: > I dug into this. Based on

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