[compiler-rt] r228384 - [UBSan] Enable -Wglobal-constructors.

[Alexey Samsonov]

On Sun, Feb 15, 2015 at 10:06 PM, Yury Gribov <y.gribov at samsung.com> wrote:

> On 02/14/2015 01:43 AM, Alexey Samsonov wrote:
>
>> On Wed, Feb 11, 2015 at 11:41 PM, Yury Gribov <y.gribov at samsung.com>
>> wrote:
>>
>>  On 02/11/2015 11:01 PM, Alexey Samsonov wrote:
>>>
>>>  On Wed, Feb 11, 2015 at 12:37 AM, Yury Gribov <y.gribov at samsung.com>
>>>> wrote:
>>>>
>>>>   On 02/11/2015 09:04 AM, Yury Gribov wrote:
>>>>
>>>>>
>>>>>   On 02/11/2015 06:07 AM, Justin Bogner wrote:
>>>>>
>>>>>>
>>>>>>   Alexey Samsonov <vonosmas at gmail.com> writes:
>>>>>>
>>>>>>>
>>>>>>>   Ah, right...
>>>>>>>
>>>>>>>> Feel free to revert this change. I have plans to deal with different
>>>>>>>> UBSan
>>>>>>>> initialization issues soon, and will see if I would be able to
>>>>>>>> reinstantiate
>>>>>>>> this warning on all platforms.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Reverted in r228795.
>>>>>>>
>>>>>>>
>>>>>>>  Can't we just move initializer to separate file for which we then
>>>>>> disable this warning?
>>>>>>
>>>>>>
>>>>>>  Does something like this make sense? It passes tests on Linux x64. I
>>>>> haven't verified OSX but I can see that -Wglobal-constructors is indeed
>>>>> disabled for ubsan_init.cc.
>>>>>
>>>>>
>>>>
>>>> In fact, I wanted to split UBSan runtime into three parts: UBSan
>>>> (UBSAN_SOURCES without ubsan_init.cc), UBSanCXX (UBSAN_CXX_SOURCES) and
>>>> UBSanStandalone (~ubsan_init.cc).
>>>> Standalone UBSan would contain all three of them, while the first two
>>>> would
>>>> also be embedded into ASan runtime. After we do this separation, it
>>>> would
>>>> be easy
>>>> to specify -Wglobal-constructors just for UBSan and UBSanCXX.
>>>>
>>>>
>>> I wonder if we should move ubsan_init.cc to ubsan_init.o and prelink it
>>> similar to how we do this with asan_preinit.o.
>>>
>>
>>
>> Not sure I understand this. We don't have shared UBSan runtime at the
>> moment.
>>
>
> Ah, another time I got hit by incompatibilities between GCC and LLVM
> sanitizers. Are there plans for dynamic runtime by the way? This could
> simplify (or actually make possible) separate sanitization of shared
> libraries.


Yeah, we could probably add a similar way to use shared UBSan runtime on
Linux (mimic ASan approach, with libubsan.so, libubsan-preinit.a, etc.)).
Note, however, that we will *not* support linking against
both ASan and standalone UBSan runtime, as each of them will have its own
copy of sanitizer_common.


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