search for: llvm_section

...e a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag", ... }; I know the COFF magic to get the section bounds to form an array, and I know it exists for ELF, but I don't know how to do it on Darwin. On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com&...

LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path. In the near term, clients who need llvm-the-library with

...alized "feature" of llvm::cl isn't all that useful, and is in some cases actively harmful. - Daniel We'd have something like: > > struct PODOptData { > const char *FlagName; > ... // Common POD stuff, can be initialized at ParseCommandLine time. > }; > > LLVM_SECTION(".llvmopt") > PODOptData OptionRegisterer = { "foo_flag", ... }; > > I know the COFF magic to get the section bounds to form an array, and I > know it exists for ELF, but I don't know how to do it on Darwin. > > > > On Tue, Sep 17, 2013 at 10:10 AM, A...