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

[Rafael Espíndola]

> 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.

Cheers,
Rafael