[patch/asan] Use lvm.global_ctors instead of symbol name matching to find constructors

Alexey Samsonov vonosmas at gmail.com
Wed May 28 17:59:42 PDT 2014


On Thu, May 22, 2014 at 6:08 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:

> Sorry for delays...
>
> Unfortunately, we won't be able to find errors on globals from template
> instantiations - see
> https://code.google.com/p/address-sanitizer/issues/detail?id=215#c2
> (tl;dr - we skip all globals with linkonce_odr linkage). Still, the patch
> looks reasonable and works on ASan test-suite with minor modifications.
>
> I'll land after a bit more testing (e.g. to verify that we won't slow down
> the code horribly).
>

... finally landed this as r209780. Thanks!



>
>
> On Tue, May 13, 2014 at 12:58 PM, Alexey Samsonov <samsonov at google.com>wrote:
>
>>
>> On Tue, May 13, 2014 at 1:30 AM, Nico Weber <thakis at chromium.org> wrote:
>>
>>> samsonov, do you want to try shepherding this in?
>>>
>>
>> Definitely. I'll try to test/land it this week.
>>
>>
>>> The patch should work as-is and it's better than what's currently there,
>>> but maybe it should happen behind a flag at first (as it might find more
>>> stuff than the current logic) – not sure about this. And there should
>>> probably some integration test, like Reid mentioned.
>>>
>>
>>
>>
>>>
>>> On Wed, May 7, 2014 at 11:41 PM, Reid Kleckner <rnk at google.com> wrote:
>>>
>>>> No, it's more basic.
>>>>
>>>> If I understand the current ASan init-order instrumentation, it only
>>>> poisons globals of other TUs during _GLOBAL__*.  Initializers of static
>>>> data members of class templates get their own llvm.global_ctors entry, so
>>>> other globals are not poisoned, and we get false negatives.
>>>>
>>>>
>>>> On Wed, May 7, 2014 at 12:46 AM, Kostya Serebryany <kcc at google.com>wrote:
>>>>
>>>>> This is
>>>>> https://code.google.com/p/address-sanitizer/issues/detail?id=215,
>>>>> isn't it?
>>>>>
>>>>>
>>>>> On Wed, May 7, 2014 at 4:07 AM, Reid Kleckner <rnk at google.com> wrote:
>>>>>
>>>>>> This is a good idea, because it will catch more bugs.  Consider this
>>>>>> C++:
>>>>>>
>>>>>> int foo();
>>>>>> template <int N> struct X { static int x; };
>>>>>> template <int N> int X<N>::x = foo();
>>>>>> int main() { return X<0>::x + X<2>::x + X<3>::x + X<4>::x; }
>>>>>>
>>>>>> This will put 4 entries into llvm.global_ctors, none of which are
>>>>>> called _GLOBAL__*.  We should probably have an ASan integration test in
>>>>>> compiler-rt for this, when foo accesses some global in a different TU.
>>>>>>
>>>>>> On the other hand, all this poisoning and unpoisoning may be
>>>>>> expensive.  We could batch up all the initializers of equal priority and
>>>>>> merge them into one initializer bracketed by calls to poison and unpoison.
>>>>>>
>>>>>>
>>>>>> On Tue, May 6, 2014 at 4:55 PM, Nico Weber <thakis at chromium.org>wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> here's how the global_ctors version would look. I haven't tested this
>>>>>>> much (it's different in that it could now instrument multiple
>>>>>>> constructors per module).
>>>>>>>
>>>>>>> Feel free to play with this, and then land this with tweaks, land it
>>>>>>> as-is, or don't land it, up to you :-)
>>>>>>>
>>>>>>> Nico
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> llvm-commits mailing list
>>>>>>> llvm-commits at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Alexey Samsonov, Mountain View, CA
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140528/da24f11f/attachment.html>


More information about the llvm-commits mailing list