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

[Yury Gribov]

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.

-Y