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

[Reid Kleckner]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/0a50cefd/attachment.html>