[LLVMdev] [RFC] Removing static initializers for command line options

[Pete Cooper]

> On Aug 26, 2014, at 11:52 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> These "debugging knobs" or library level options which *aren't* exposed in
>> the library's APIs are very risky to expose in a side-channel API: they are
>> often completely unsupported or unsupportable options that were never
>> intended for "production" usage. Once we expose these options via some API
>> to library users, we run a very serious risk of getting locked into
>> supporting behaviors or debugging misbehavior that were never expected or
>> planned for...
> 
> Agreed. This is my only real concern in here.
> 
>> However, the debugging use case is real and important. So I want to propose
>> that we guard many of the paths to setting these options with NDEBUG so that
>> in non-asserts builds, library users can't override these options. This
>> would mean the C++ API for setting this in LLVMContext (and the C API if we
>> ever expose it there) would only support setting these in asserts builds. We
>> could even sink the checking into the registry. The name should probably
>> have "debug" in it somewhere. It would then have some
>> InternalUnsupportedScaryBad API which is not actually in the header files
>> but is used in LLVM's tools to maintain their current behavior without
>> documenting a public API. It's not bulletproof, but it seemed that it would
>> be sufficient for the debugging use cases and is a strong statement of
>> "unsupported" IMO.
> 
> Just to be clear, the idea is that in a release build the only way of
> setting options is via the command line? That they can still be passed
> to opt or llc, but they would not be considered part of the API.
> 
>> - I really like the idea of using a 'void*' derived from some static tag as
>> a way to identify uniquely each option. I also think we can use some minimal
>> "reflection" techniques to significantly simplify this.
> 
> I like it too. The reason I do is that it is one more layer in a
> defense in depth against making our internal options part of the API.
> The key is not just a well known value (like a string).
> 
>> - I'd like to avoid a separate "option store". My current suggestion is to
>> use the LLVMContext, and to add a context to the layers which don't have an
>> LLVMContext and where these kinds of options make sense.
> 
> I agree. There are few places in LLVM without a LLVMContext. For
> example, there is one cl::opt in lib/MC and Joerg already has a patch
> to turn it into a proper API.
I disagree with this point.  The majority of the fields of the context are IR.  An MC only tool should not be required to link the LLVM IR just because they want to use a command line option.

Chris’ suggestion is to make an OptionStore class and pass it throughout the APIs where we want to handle options.  At first the store should be a global singleton.  Users of options don’t need to know about the LLVMContext or any other unrelated data structure.  If the options are stored as a field of the context then that can easily be done too.

If we later decide that the OptionStore should live in the LLVMContext or any other location then thats fine, but moving it to that point would be a minimal change as no APIs have to be rewritten.  Also, if we decide that we want the LLVMContext to have an option store, but MC level tools to be allowed to define their own, then that would also be possible.

Thanks,
Pete
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev