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

Nico Weber thakis at chromium.org
Tue May 13 01:30:09 PDT 2014


samsonov, do you want to try shepherding this in? 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140513/3fdf3395/attachment.html>


More information about the llvm-commits mailing list