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

Alexey Samsonov vonosmas at gmail.com
Thu May 22 18:08:22 PDT 2014


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).


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140522/0c6dd07b/attachment.html>


More information about the llvm-commits mailing list