<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">+kremenek, ganna <br><br><div class="gmail_quote">On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <span dir="ltr"><<a href="mailto:howarth@bromo.med.uc.edu" target="_blank">howarth@bromo.med.uc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote:<br>
</div><div class="im">> Just want to remind everyone that we plan to stop using mach_override in<br>
> asanin favor of OSX's native function interposition.<br>
> So, we probably don't want to spend too much effort fixing mach_override.<br>
><br>
> --kcc<br>
<br>
</div>Kostya,<br>
Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,<br>
using MAC_INTERPOSE_FUNCTIONS on FSF gcc will require the missing blocks support<br>
to be implemented. I did a quick and dirty attempt to build libasan using<br>
libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm svn.<br>
The bootstrap chokes on...<br></blockquote><div><br></div><div>Alex is the expert in the OSX side of things, hopefully he can comment. </div><div><br></div><div>But our situation wrt asan on OSX is as I see it: </div><div>
- mach_override does not work: we spent more time fighting with mach_override's stability than we spent on implementing all of asan for linux. And there are still bugs we don't know how to fix. </div><div> - mach_override does not work: it is not supported on iOS and (may not be supported) on later versions of OSX</div>
<div>So, there is no choice for us but to use the Apple-blessed mechanism. </div><div><br></div><div>Do we want to support both? </div><div>No, that's too expensive. And very likely once we move to function interposition, mach_override will rot very soon. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/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/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/testsuite/util -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/ -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0 -DASAN_NEEDS_SEGV=1 -DMAC_INTERPOSE_FUNCTIONS -I. -I../../../../gcc-4.8-20121130/libsanitizer/asan -I ../../../../gcc-4.8-20121130/libsanitizer/include -I ../../../../gcc-4.8-20121130/libsanitizer -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -Wno-c99-extensions -g -O2 -MT asan_interceptors.lo -MD -MP -MF .deps/asan_interceptors.Tpo -c -o asan_interceptors.lo ../../../../gcc-4.8-20121130/libsanitizer/asan/asan_interceptors.cc<br>
libtool: 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/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121130/libstdc++-v3/testsuite/util -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/ -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0 -DASAN_NEEDS_SEGV=1 -DMAC_INTERPOSE_FUNCTIONS -I. -I../../../../gcc-4.8-20121130/libsanitizer/asan -I ../../../../gcc-4.8-20121130/libsanitizer/include -I ../../../../gcc-4.8-20121130/libsanitizer -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -Wno-c99-extensions -g -O2 -MT asan_interceptors.lo -MD -MP -MF .deps/asan_interceptors.Tpo -c ../../../../gcc-4.8-20121130/libsanitizer/asan/asan_interceptors.cc -fno-common -DPIC -o .libs/asan_interceptors.o<br>
In file included from ../../../../gcc-4.8-20121130/libsanitizer/asan/asan_interceptors.cc:15:0:<br>
../../../../gcc-4.8-20121130/libsanitizer/asan/asan_intercepted_functions.h:209:57: error: expected ‘)’ before ‘^’ token<br>
dispatch_queue_t dq, void (^work)(void));<br>
^<br>
etc. So we may be stuck with mach_override until someone steps up to implement the missing blocks support for darwin in FSF gcc.<br></blockquote><div><br></div><div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"> Jack<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>>wrote:<br>
><br>
> > Looks like this happens on x86_64 because the position of __cxa_throw<br>
> > is too far from the allocated branch island (should be <2G). This can<br>
> > be solved by allocating the branch islands somewhere near the text<br>
> > segment (look for kIslandEnd in asan_mac.cc, this is currently<br>
> > 0x7fffffdf0000) or by patching the function with a longer instruction<br>
> > sequence that stores the jump target in a register and jumps to that<br>
> > target (which is a bit more complex to implement).<br>
> ><br>
> > Once this problem is fixed, another one is going to arise. This is how<br>
> > the first bytes of __cxa_throw look like:<br>
> ><br>
> > 0x0020c49ba5d916e0 <__cxa_throw+0>: lea 0xb4f01(%rip),%rax #<br>
> > 0x20c49ba5e465e8 <_ZN10__cxxabiv120__unexpected_handlerE><br>
> > 0x0020c49ba5d916e7 <__cxa_throw+7>: push %rbx<br>
> > 0x0020c49ba5d916e8 <__cxa_throw+8>: lea -0x20(%rdi),%rbx<br>
> ><br>
> > If we move the relative LEA instruction somewhere, we must fix the<br>
> > constant in order to keep it pointing to the same address.<br>
> > mach_override already does this for relative CALL and JMP<br>
> > instructions, but not for LEA. This should be fairly simple to fix.<br>
> ><br>
> > Note that the 32-bit variant crashes on another invalid address:<br>
> ><br>
> > ASAN:SIGSEGV<br>
> > =================================================================<br>
> > ==89768== ERROR: AddressSanitizer: SEGV on unknown address 0xcccccccc<br>
> > (pc 0x00061f8c sp 0xbffa8bd0 bp 0xbffa8cc8 T0)<br>
> > AddressSanitizer can not provide additional info.<br>
> > #0 0x61f8b<br>
> > (/Users/glider/src/gcc-asan/inst/lib/i386/libstdc++.6.dylib+0x3f8b)<br>
> > #1 0x91391724 (/usr/lib/system/libdyld.dylib+0x2724)<br>
> > #2 0x0<br>
> > Stats: 0M malloced (0M for red zones) by 3 calls<br>
> > Stats: 0M realloced by 0 calls<br>
> > Stats: 0M freed by 0 calls<br>
> > Stats: 0M really freed by 0 calls<br>
> > Stats: 1M (256 full pages) mmaped in 2 calls<br>
> > mmaps by size class: 7:4095; 8:2047;<br>
> > mallocs by size class: 7:1; 8:2;<br>
> > frees by size class:<br>
> > rfrees by size class:<br>
> > Stats: malloc large: 0 small slow: 2<br>
> > ==89768== ABORTING<br>
> ><br>
> > My guess is that this is caused by the following code being moved to a<br>
> > branch island:<br>
> ><br>
> > Dump of assembler code for function __cxa_throw:<br>
> > 0x00008f60 <__cxa_throw+0>: push %esi<br>
> > 0x00008f61 <__cxa_throw+1>: push %ebx<br>
> > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx><br>
> ><br>
> > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value.<br>
> ><br>
> > Since libstdc++-v3 is built together with gcc, the two issues related<br>
> > to instructions being moved to another place can be solved by padding<br>
> > __cxa_throw() with five NOP instructions (enough to hold a JMP). I<br>
> > believe this should be acceptable, because the performance penalty for<br>
> > additional NOPs is negligible, and __cxa_throw() isn't a hot point.<br>
> ><br>
> > On Thu, Nov 29, 2012 at 1:01 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
> > > I debugged this a bit and it seems the mach_override patching of<br>
> > __cxa_throw is bogus. The start of that function is patched to jump to<br>
> > garbage.<br>
> > ><br>
> > > Breakpoint 1, 0x0000000100001c19 in main ()<br>
> > > (gdb) display/i $pc<br>
> > > 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386<br>
> > <dyld_stub___cxa_throw><br>
> > > (gdb) si<br>
> > > 0x0000000100016386 in dyld_stub___cxa_throw ()<br>
> > > 2: x/i $pc 0x100016386 <dyld_stub___cxa_throw>: jmpq<br>
> > *0xae1c(%rip) # 0x1000211a8<br>
> > > (gdb)<br>
> > > 0x0000000102244870 in __cxa_throw ()<br>
> > > 2: x/i $pc 0x102244870 <__cxa_throw>: jmpq 0xffd27000<br>
> > > (gdb) # the above its __cxa_throw in gcc's libstdc++.6.dylib. The<br>
> > first instruction has been patch to jump to a garbage address.<br>
> > ><br>
> > > (gdb) x/8i 0x102244870-8<br>
> > > 0x102244868<br>
> > <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+56>:<br>
> > std<br>
> > > 0x102244869<br>
> > <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+57>:<br>
> > (bad)<br>
> > > 0x10224486a<br>
> > <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+58>:<br>
> > decl (%rdi)<br>
> > > 0x10224486c<br>
> > <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+60>:<br>
> > (bad)<br>
> > > 0x10224486d<br>
> > <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+61>:<br>
> > add %r8b,(%rax)<br>
> > > 0x102244870 <__cxa_throw>: jmpq 0xffd27000<br>
> > > 0x102244875 <__cxa_throw+5>: or (%rax),%eax<br>
> > > 0x102244877 <__cxa_throw+7>: push %rbx<br>
> > > (gdb)<br>
> > > (gdb) watch *0x102244870<br>
> > > Hardware watchpoint 2: *4330899568<br>
> > > (gdb) r<br>
> > ><br>
> > > Old value = -788165304<br>
> > > New value = -1373139991<br>
> > > 0x0000000100016203 in __asan_mach_override_ptr_custom ()<br>
> > > (gdb) bt<br>
> > > #0 0x0000000100016203 in __asan_mach_override_ptr_custom ()<br>
> > > #1 0x0000000100015a9e in __interception::OverrideFunction ()<br>
> > > #2 0x00007fff5fc13378 in ImageLoaderMachO::doModInitFunctions ()<br>
> > > #3 0x00007fff5fc13762 in ImageLoaderMachO::doInitialization ()<br>
> > > #4 0x00007fff5fc1006e in ImageLoader::recursiveInitialization ()<br>
> > > #5 0x00007fff5fc0feba in ImageLoader::runInitializers ()<br>
> > > #6 0x00007fff5fc01fc0 in dyld::initializeMainExecutable ()<br>
> > > #7 0x00007fff5fc05b04 in dyld::_main ()<br>
> > > #8 0x00007fff5fc01397 in dyldbootstrap::start ()<br>
> > > #9 0x00007fff5fc0105e in _dyld_start ()<br>
> > > (gdb) x/8i 0x102244870<br>
> > > 0x102244870 <__cxa_throw>: jmpq 0xffd27000<br>
> > > 0x102244875 <__cxa_throw+5>: or (%rax),%eax<br>
> > > 0x102244877 <__cxa_throw+7>: push %rbx<br>
> > > 0x102244878 <__cxa_throw+8>: lea -0x20(%rdi),%rbx<br>
> > > 0x10224487c <__cxa_throw+12>: mov %rsi,-0x70(%rdi)<br>
> > > # Here is where the patching is being done<br>
> > ><br>
> > > -Nick<br>
> > ><br>
> > > On Nov 29, 2012, at 11:07 AM, Alexander Potapenko wrote:<br>
> > >>> On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <<br>
> > <a href="mailto:howarth@bromo.med.uc.edu">howarth@bromo.med.uc.edu</a>><br>
> > >>> wrote:<br>
> > >>>><br>
> > >>>> Nick,<br>
> > >>>> Can you take a quick look at the <a href="http://asan_eh_bug.tar.bz" target="_blank">asan_eh_bug.tar.bz</a> testcase<br>
> > >>>> I uploaded into the newly opened radr://12777299, "potential<br>
> > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers<br>
> > >>>> have ported <a href="http://llvm.org" target="_blank">llvm.org</a>'s asan code into FSF gcc (and are keeping<br>
> > >>>> it synced to the upstream <a href="http://llvm.org" target="_blank">llvm.org</a> code). I have been helping<br>
> > >>>> with the darwin build and testing -fsanitize=address against the<br>
> > >>>> complete FSF gcc testsuite. This seems to have exposed a potential<br>
> > >>>> bug in pthread or eh on darwin under libasan. Hundreds of test cases<br>
> > >>>> in the g++ and libstdc++ testsuites fail under -fsanitize=address<br>
> > >>>> in the following manner...<br>
> > >>>><br>
> > >>>> ASAN:SIGSEGV<br>
> > >>>> =================================================================<br>
> > >>>> ==2738== ERROR: AddressSanitizer: SEGV on unknown address<br>
> > 0x0000ffd27000<br>
> > >>>> (pc 0x0000ffd27000 sp 0x7fff55e40828 bp 0x7fff55e408f0 T0)<br>
> > >>>> AddressSanitizer can not provide additional info.<br>
> > >>>> #0 0xffd26fff<br>
> > (/Users/howarth/asan_eh_bug/./cond1_asan.exe+0xf5f67fff)<br>
> > >>>> #1 0x7fff8bd827e0 (/usr/lib/system/libdyld.dylib+0x27e0)<br>
> > >>>> #2 0x0<br>
> > >>>> Stats: 0M malloced (0M for red zones) by 3 calls<br>
> > >>>> Stats: 0M realloced by 0 calls<br>
> > >>>> Stats: 0M freed by 0 calls<br>
> > >>>> Stats: 0M really freed by 0 calls<br>
> > >>>> Stats: 1M (384 full pages) mmaped in 3 calls<br>
> > >>>> mmaps by size class: 7:4095; 8:2047; 9:1023;<br>
> > >>>> mallocs by size class: 7:1; 8:1; 9:1;<br>
> > >>>> frees by size class:<br>
> > >>>> rfrees by size class:<br>
> > >>>> Stats: malloc large: 0 small slow: 3<br>
> > >>>> ==2738== ABORTING<br>
> > >>>><br>
> > >>>> The failure of...<br>
> > >>>><br>
> > >>>> FAIL: g++.dg/eh/cond1.C -std=c++98 execution test<br>
> > >>>><br>
> > >>>> was used as the test case for the radar report and compiled with...<br>
> > >>>><br>
> > >>>> g++-fsf-4.8 -static-libasan -fsanitize=address -std=c++98 cond1.C -g<br>
> > -O0<br>
> > >>>> -o cond1_asan.exe<br>
> > >>>><br>
> > >>>> to produce the above failure. When compiled without libasan as...<br>
> > >>>><br>
> > >>>> g++-fsf-4.8 -std=c++98 cond1.C -g -O0 -o cond1_no_asan.exe<br>
> > >>>><br>
> > >>>> the resulting executable runs fine. Debugging this in gdb seems to<br>
> > show<br>
> > >>>> that the failure<br>
> > >>>> is occuring in the final call to dyld_stub_pthread_once (). The same<br>
> > test<br>
> > >>>> case<br>
> > >>>> compiles fine with -fsanitize=address under llvm 3.2 clang++ and<br>
> > produces<br>
> > >>>> no runtime errors<br>
> > >>>> but the code execution path is very different in that case (because<br>
> > of the<br>
> > >>>> different<br>
> > >>>> libstdc++).<br>
> > >>>> Can you take a quick peek at this and determine if this is a darwin<br>
> > >>>> pthread or unwinder<br>
> > >>>> bug or an issue with libasan that FSF gcc's compiler is exposing?<br>
> > Thanks<br>
> > >>>> in advance for<br>
> > >>>> any help on this.<br>
> > >>>> Jack<br>
> > >>>> _______________________________________________<br>
> > >>>> LLVM Developers mailing list<br>
> > >>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > >>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
> > >>><br>
> > >>><br>
> > >><br>
> > >><br>
> > >><br>
> > >> --<br>
> > >> Alexander Potapenko<br>
> > >> Software Engineer<br>
> > >> Google Moscow<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Alexander Potapenko<br>
> > Software Engineer<br>
> > Google Moscow<br>
> ><br>
</div></div></blockquote></div><br></div>