rnk added inline comments.

================
Comment at: lib/CodeGen/CGBlocks.cpp:1276
+    InitVar->setSection(".CRT$XCLa");
+    CGM.addUsedGlobal(InitVar);
+  }
----------------
mstorsjo wrote:
> 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.
I filed a bug to turn the integers into strings on COFF: 
https://bugs.llvm.org/show_bug.cgi?id=38552


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

Reply via email to