[PATCH] D50144: Add Windows support for the GNUstep Objective-C ABI V2.

Martin Storsjö via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 8 00:44:37 PDT 2018


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





More information about the cfe-commits mailing list