[cfe-dev] Static constructors: _cxx_global_var_initN vs _GLOBAL__sub_I_XXX

Reid Kleckner via cfe-dev cfe-dev at lists.llvm.org
Mon Jan 11 16:18:36 PST 2016


It's documented:
http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable

OK, I apologize, it's terse. :)

The third field is a global whose comdat group the initializer should be
in. On Windows, this is the mechanism that prevents double initialization
of static data members of class templates. On Linux, it is an optimization
that improves startup time and code size.

If the third field would be null, then we lump the initialization into the
__GLOBAL_sub_I... function to allow for inilining, etc, as David explained.

On Thu, Jan 7, 2016 at 1:36 AM, Andrew Parker via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I'm trying to understand more about global constructors generated by
> clang. As far as I understand it, any compilation unit which requires
> static constructors will cause clang to generate LLVM IR to append to the
> array:
>
> @llvm.global_ctors
>
> This is an array of structs with 3 elements: a priority, a function
> pointer and an unknown (seemingly undocumented) member.
>
> In most cases I only ever see one element in this array (per compilation
> unit) with name _GLOBAL__sub_I_Filename.cpp.
>
> However in some more complex cases - which I've yet to pin down but I
> think relates to templates - I see multiple members. Those members always
> seem to look something like:
>
> __cxx_global_var_init89
> __cxx_global_var_init90
> _GLOBAL__sub_I_Filename.cpp
>
> Furthermore, the last function usually just wraps other functions with
> names prefixed by __cxx_global_var_init, e.g.
>
> declare i8* @memset(i8*, i32, i64) #0
> define internal void @__s3e__GLOBAL__sub_I_Filename.cpp() #0 {
>   call void @__cxx_global_var_init(), !dbg !32933
>   call void @__cxx_global_var_init1(), !dbg !32933
>   call void @__cxx_global_var_init2(), !dbg !32933
>   ret void
> }
>
> I'd just like to understand what the logic is behind the generation of
> these functions. It looks to me like there's implicit constructor priority
> however the priority member of the @llvm.global_ctors array is never used
> (well, it's always 65535).
>
> Does anyone know the secrets behind this?
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160111/108f41af/attachment.html>


More information about the cfe-dev mailing list