[LLVMdev] [RFC] Internal command line options should not be statically initialized.

[ChanMaxthon]

So since you are rolling that then why don't just use the simpler ARM ELF ABI for that? armv7a ABI on i386 and AArch64 ABI in amd64? That init-array are dead simple to use.

Sent from my iPhone

> On 2013年9月18日, at 2:29, Reid Kleckner <rnk at google.com> wrote:
> 
> Wait, I have 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> wrote:
>> 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 no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing.
>> 
>> A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers are irrelevant.
>> 
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT build mode. This can be done by making the -Asserts build just as strict. In the meantime, we would like to run as many unit tests as possible with LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt definitions buried within LLVM libraries to to a new pattern that avoids static initialization.
>> 
>> One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no initialization.
>> 
>> MyPass() {
>>   // Only registers an option with the same optval once.
>>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                          cl::desc("Descriptive string..."), );
>> }
>> 
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/5ac41347/attachment.html>