[PATCH] Fix PR55521 by switching libsanitizer from mach_override to mac interpose functions on darwin

[Konstantin Serebryany]

On Sun, Dec 2, 2012 at 10:21 AM, Alexander Potapenko <glider@google.com> wrote:
> Hi Jack,
>
> IIUC the wrappers for dispatch_async_f, dispatch_sync_f and other
> dispatch_smth_f do not need blocks support in the compiler, since
> regular functions are passed into them. So you may want to add the
> dynamic interceptors for those back.
> The remaining problem is that dispach_async and other functions using
> blocks won't be intercepted. This may lead to assertion failures in
> big projects (e.g. we needed those for Chrome).
> Overall, the change looks good. Do you want me to backport
> MISSING_BLOCKS_SUPPORT into the LLVM version of the runtime?

Please remember that all non-trivial patches to files that exist in
the upstream (llvm) repository should go there first.
Otherwise we'll be drown in merges.

--kcc

>
> Alex
>
> On Sun, Dec 2, 2012 at 6:43 AM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
>>    The attached patch eliminates PR 55521/sanitizer by switching libasan on darwin
>> from using mach_override to mac function interposition via the importation of the
>> asan/dynamic/asan_interceptors_dynamic.cc file from llvm.org's compiler-rt svn.
>> The changes involve defining USING_MAC_INTERPOSE in configure.ac rather than
>> rather than USING_MACH_OVERRIDE, introduction of the use of USING_MAC_INTERPOSE
>> in Makefile.am to avoid building the interception subdirectory, the passage of
>> -DMAC_INTERPOSE_FUNCTIONS in asan/Makefile.am when USING_MAC_INTERPOSE as well as
>> the introduction of a -DMISSING_BLOCKS_SUPPORT flag to disable code that requires
>> blocks support which FSF gcc lacks. The depreciated usage of USING_MACH_OVERRIDE
>> is also removed from interception/Makefile.am. Bootstrapped on x86_64-apple-darwin10,
>> x86_64-apple-darwin11 and x86_64-apple-darwin12. Passes...
>>
>> make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"
>>
>> and fixes the previously failing cond1.C test case from PR55521 on all three targets.
>> Okay for gcc trunk?
>>               Jack
>>
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow