[PATCH] [ASan] Make BlockingMutex really linker initialized.

Yury Gribov y.gribov at samsung.com
Wed Feb 18 05:29:17 PST 2015

On 02/06/2015 09:10 AM, Yury Gribov wrote:
> On 02/04/2015 07:23 PM, David Blaikie wrote:
>> On Wed, Feb 4, 2015 at 3:56 AM, Yury Gribov <tetra2005 at gmail.com> wrote:
>>>> Yes, I think enabling -Wglobal-constructors for ASan (and for all the
>>> rest sanitizers) will be great.
>>> FYI it was relatively easy to get this working on Linux (with ~500 lines
>>> of changes). Unfortunately Windows compiler lacks too many necessary
>>> features: explicit initialization of array members, constexpr,
>>> unrestricted
>>> unions (all still missing in VS2013 and we still use VS2012). Having #if
>>> WINDOWS all over the place isn't an option as well so I'm afraid we
>>> are out
>>> of luck.
>> Perhaps there's a relatively small number of structures (probably
>> templates) we could create to keep all of this logic (and Windows
>> workarounds/suppressions) in one place so it could scale to all the use
>> cases we have?
> Thanks for the idea, I'll check this next week.


Here is a draft version (not full-blown patch but rather a PoC). The 
main part is in sanitizer_internal_defs.h (classes 
LinkerInitializedArray and LinkerInitializedStructArray). I also 
slightly changed atomic types in sanitizer_atomic.h (volatile members 
can't be linker-initialized). Does this look sane in general?

I've did full rebuild and regtests on Linux (compiler-rt built by trunk 
Clang, GCC 4.8 and Clang 3.1). I haven't done full testing on Windows 
and Mac but at least relevant parts of sanitizer_internal_defs.h 
compiled fine.

If all this makes sense, how should I proceed with a refactoring of this 
scale? Is it mandatory to verify _all_ platforms or I could to some 
extent rely on respected maintainers to fix errors? The former would be 
quite a burden.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: asan-global-ctors-2.diff
Type: text/x-patch
Size: 51872 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150218/fcbc7dd2/attachment.bin>

More information about the llvm-commits mailing list