[cfe-commits] r169328 - in /cfe/trunk: lib/Driver/Tools.cpp test/Driver/asan-ld.c
Evgeniy Stepanov
eugenis at google.com
Wed Dec 5 01:30:59 PST 2012
We could reimplement the __cxa_guard_* stuff in TSan...
On Wed, Dec 5, 2012 at 12:47 PM, Kostya Serebryany <kcc at google.com> wrote:
> And with tsan the situation is worse because it has to
> intercept __cxa_guard_acquire/__cxa_guard_release,
>
>
> On Wed, Dec 5, 2012 at 12:45 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Wed, Dec 5, 2012 at 12:36 PM, Chandler Carruth <chandlerc at gmail.com>wrote:
>>
>>> On Wed, Dec 5, 2012 at 12:13 AM, Kostya Serebryany <kcc at google.com>wrote:
>>>
>>>> +asan/tsan/msan folks
>>>>
>>>> That's not as simple as this, I afraid.
>>>> In *san there are two different kinds of interceptors.
>>>> 1. foo from libc/libstc++ is completely replaced with foo from asan.
>>>> Example: malloc, operator new
>>>> 2. foo from libc/libstc++ is wrapped, such that when a user calls foo
>>>> it calls the asan copy, but then the asan function calls the original foo.
>>>> Example: pthread_create, __cxa_throw
>>>>
>>>> This change allows to use -static-libstdc++ with asan w/o link
>>>> failures, but asan is still broken for -static-libstdc++ in a subtle way
>>>> (since the __cxa_throw is not intercepted, asan will have rare false
>>>> positives in presence of exceptions).
>>>>
>>>
>>> Can you describe the rare false positive? What would be needed to fully
>>> fix this?
>>>
>>
>> __cxa_throw is unfriendly to asan as it never returns from the current
>> function.
>> If there is poisoned stack it will neve get unpoisoned after throw. Some
>> one else later will step on the poisoned stack and get a false positive.
>> This is why we
>> 1. Intercept __cxa_throw and call __asan_handle_no_return
>> (asan/asan_interceptors.cc)
>> 2. We also call __asan_handle_no_return before any noreturn call when
>> we instrument it.
>>
>> Today if you use -static-libstdc++ the asan's __cxa_throw interceptor is
>> not called.
>> So, if a throw happens in a code that we don't instrument, we will not
>> call __asan_handle_no_return at all. Booom.
>>
>>
>>
>>
>>>
>>>
>>>> Tsan also intercepts __cxa_guard in the similar way, so it will have
>>>> false positives on function scope statics.
>>>>
>>>> Do we really care that much about linking asan with static libstdc++?
>>>>
>>>
>>> In my opinion, yes. We already have too much that is special about
>>> linking with asan....
>>>
>>
>> Well, yes. E.g. it does not support fully static linking at all, and
>> hardly ever will.
>>
>> --kcc
>>
>>
>>
>>>
>>>
>>>>
>>>> --kcc
>>>>
>>>>
>>>> On Wed, Dec 5, 2012 at 2:54 AM, Chandler Carruth <chandlerc at gmail.com>wrote:
>>>>
>>>>> Author: chandlerc
>>>>> Date: Tue Dec 4 16:54:37 2012
>>>>> New Revision: 169328
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=169328&view=rev
>>>>> Log:
>>>>> Add -whole-archive around the ASan runtime archive in the link command.
>>>>>
>>>>> This ensures that even though it comes first, we pick up its .o files.
>>>>> Note that if we can use this (or something similar / equivalent) on
>>>>> other platforms, we could potentially remove
>>>>> ReplaceOperatorsNewAndDelete from the ASan runtimes.
>>>>>
>>>>> We should probably do something similar for TSan and MSan as well.
>>>>>
>>>>> Modified:
>>>>> cfe/trunk/lib/Driver/Tools.cpp
>>>>> cfe/trunk/test/Driver/asan-ld.c
>>>>>
>>>>> Modified: cfe/trunk/lib/Driver/Tools.cpp
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=169328&r1=169327&r2=169328&view=diff
>>>>>
>>>>> ==============================================================================
>>>>> --- cfe/trunk/lib/Driver/Tools.cpp (original)
>>>>> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Dec 4 16:54:37 2012
>>>>> @@ -1524,8 +1524,14 @@
>>>>> // The ASan runtime needs to come before -lstdc++ (or -lc++,
>>>>> libstdc++.a,
>>>>> // etc.) so that the linker picks ASan's versions of the global
>>>>> 'operator
>>>>> // new' and 'operator delete' symbols. We take the extreme (but
>>>>> simple)
>>>>> - // strategy of inserting it at the front of the link command.
>>>>> - CmdArgs.insert(CmdArgs.begin(), Args.MakeArgString(LibAsan));
>>>>> + // strategy of inserting it at the front of the link command.
>>>>> It also
>>>>> + // needs to be forced to end up in the executable, so wrap it in
>>>>> + // whole-archive.
>>>>> + SmallVector<const char*, 3> PrefixArgs;
>>>>> + PrefixArgs.push_back("-whole-archive");
>>>>> + PrefixArgs.push_back(Args.MakeArgString(LibAsan));
>>>>> + PrefixArgs.push_back("-no-whole-archive");
>>>>> + CmdArgs.insert(CmdArgs.begin(), PrefixArgs.begin(),
>>>>> PrefixArgs.end());
>>>>> CmdArgs.push_back("-lpthread");
>>>>> CmdArgs.push_back("-ldl");
>>>>> CmdArgs.push_back("-export-dynamic");
>>>>>
>>>>> Modified: cfe/trunk/test/Driver/asan-ld.c
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/asan-ld.c?rev=169328&r1=169327&r2=169328&view=diff
>>>>>
>>>>> ==============================================================================
>>>>> --- cfe/trunk/test/Driver/asan-ld.c (original)
>>>>> +++ cfe/trunk/test/Driver/asan-ld.c Tue Dec 4 16:54:37 2012
>>>>> @@ -19,7 +19,7 @@
>>>>> //
>>>>> // CHECK-LINUX-CXX: "{{.*}}ld{{(.exe)?}}"
>>>>> // CHECK-LINUX-CXX-NOT: "-lc"
>>>>> -// CHECK-LINUX-CXX: libclang_rt.asan-i386.a"
>>>>> +// CHECK-LINUX-CXX: "-whole-archive" "{{.*}}libclang_rt.asan-i386.a"
>>>>> "-no-whole-archive"
>>>>> // CHECK-LINUX-CXX: "-lpthread"
>>>>> // CHECK-LINUX-CXX: "-ldl"
>>>>> // CHECK-LINUX-CXX: "-export-dynamic"
>>>>> @@ -32,7 +32,7 @@
>>>>> //
>>>>> // CHECK-LINUX-CXX-STATIC: "{{.*}}ld{{(.exe)?}}"
>>>>> // CHECK-LINUX-CXX-STATIC-NOT: stdc++
>>>>> -// CHECK-LINUX-CXX-STATIC: libclang_rt.asan-i386.a"
>>>>> +// CHECK-LINUX-CXX-STATIC: "-whole-archive"
>>>>> "{{.*}}libclang_rt.asan-i386.a" "-no-whole-archive"
>>>>> // CHECK-LINUX-CXX-STATIC: stdc++
>>>>>
>>>>> // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-commits mailing list
>>>>> cfe-commits at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121205/2bf701ed/attachment.html>
More information about the cfe-commits
mailing list