mstorsjo added inline comments.
================
Comment at: lib/CodeGen/CGBlocks.cpp:1276
+ InitVar->setSection(".CRT$XCLa");
+ CGM.addUsedGlobal(InitVar);
+ }
----------------
rjmccall wrote:
> DHowett-MSFT wrote:
> > rjmccall wrote:
> > > Is the priority system not good enough?
> > My reading of the LLVM language reference leads me to believe it’s only
> > ordered per-module. If that’s the case, the benefit of emitting into `XC*`
> > is that it provides guaranteed order over all linker input.
> >
> > `llvm.global_ctors` excerpt:
> >
> > > The functions referenced by this array will be called in ascending order
> > > of priority (i.e. lowest first) when the module is loaded.
> >
> > Now if the priority system _is_ guaranteed over all linker input, will that
> > guarantee hold for mixed Clang and CL objects?
> Init priorities on ELF are preserved in the section name like
> `.init_array.200`, and the sections get sorted by that in the image — it's
> really a very similar trick to how it works with `.CRT$XC`. Of the major
> formats, I think it's just Mach-O that doesn't have any built-in
> prioritization mechanism across object files. But I don't know if LLVM
> actually tries to translate init priorities over into `.CRT$XC` suffices when
> targeting PE/COFF, and arguably that's good: init priorities as presented in
> LLVM right now are pretty specific to the ELF mechanism. Long-term, maybe
> `llvm.global_ctors` should be generalized so that on ELF targets it takes an
> integer priority, on PE/COFF targets it takes a string, and on Mach-O it
> doesn't take anything at all; but I won't hold up this patch for that.
>
> On the other hand, I tend to agree that maybe the best solution is for the
> backend to just take care of this and automatically create a global
> initializer to install non-function (or maybe non-function & `unnamed_addr`)
> `dllimport`ed symbols in global data.
> But I don't know if LLVM actually tries to translate init priorities over
> into .CRT$XC suffices when targeting PE/COFF, and arguably that's good: init
> priorities as presented in LLVM right now are pretty specific to the ELF
> mechanism. Long-term, maybe llvm.global_ctors should be generalized so that
> on ELF targets it takes an integer priority, on PE/COFF targets it takes a
> string, and on Mach-O it doesn't take anything at all; but I won't hold up
> this patch for that.
FWIW, for the MinGW targets, the same ELF-like priority system is used (or I
think it's actually an older mechanism previously used on ELF); constructors
are emitted in `.ctors`, and those with a priority go into sections named
`.ctors.01234` where the number is 65535 minus the init priority specified. By
making these zero padded, they get ordered right by the normal alphabetical
sorting. MinGW CRT startup routines then have extra code to run constructors in
the right order from the `.ctors` section, in addition to the normal `.CRT$XC`
ones.
Repository:
rC Clang
https://reviews.llvm.org/D50144
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
