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

[Chandler Carruth]

I'll try to provide some feedback on this patch assuming that we want to
try to completely move away from global variables in a single step
(something that I do generally support, although I don't understand why a
more incremental approach is unacceptable -- it seems like a bit more work
over all but a somewhat smoother transition for the community).

I feel like the APIs you're ending up with are bending around backwards to
achieve things that it isn't even clear are valuable:

1) They seem to be trying to working very hard to behave similarly to the
existing cl::opt interfaces. If we're so radically changing the core design
of cl::opt, different interfaces might be in order.

2) Perhaps this was explained up-thread (I'm going to try to read most of
the older posts, but I'm still catching up on this thread) but if we're
going this direction I would really expect the options to be
per-LLVMContext... I feel like these are just "lazy globals with private
storage" which don't seem all that conceptually better than globals.
They've just engineered around the technical problems caused.

3) I really dislike the whole INITIALIZE_PASS_{BEGIN,END} pattern. I'm not
sure if there is any realistic alternative, but I'm expecting to
essentially have to rework every single one of these for the new pass
manager. =[


I'm going to try to read Sean's proposal, but I'm suspect it is essentially
a strongly typed option registry inside the LLVMContext? With some way to
collect the options first and then to parse flags? That kind of approach
seems more likely to really solve this issue once and for all and be an
excellent, and scalable long-term solution... but as I said, I'm still
catching up on the thread. I'll try to post more coherent thoughts when
I've had time to read the other posts fully and skim through the other
proposals.



On Wed, Aug 20, 2014 at 12:45 PM, Chris Bieneman <cbieneman at apple.com>
wrote:

> I think Rafael’s suggestion of using the address of a global as the key to
> the option store gives us the ability to accomplish all our goals without
> introducing a string keyed option store.
>
> I’ve updated my patches from the original proposal to reflect those
> changes.
>
> Does this look reasonable?
>
> Thanks,
> -Chris
>
>
> > On Aug 20, 2014, at 12:41 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> >
> >>> Pass the passinfo to the pass constructor maybe?
> >>>
> >>> I still don't understand what the problem with the global is. It has
> >>> the same value for all users. As Chandler pointed out, having
> >>
> >> Globals are bad for many reasons: namespace pollution, concurrency
> issues, lack of access control, etc. etc.. Some of them have been discussed
> in this thread. Perhaps it’s not a big concern for most of the LLVM users.
> But we have an unique environment where LLVM is shared by multiple clients,
> and where the concern around exploits are especially strong. So while
> eliminating globals is not strictly tied to the elimination of static
> initializers, it is still a strong goal towards providing a LLVM dylib.
> >
> > Fair enough. I would still make at separate stage since how to remove
> > them is the part that is still a bit contentious. Note that from a
> > security point of view a well known string probably makes things worse
> > than the global option storage since the address of the storage is at
> > least randomized.
> >
> > It seems that both mine and Peter's proposal would avoid the global
> > storage and not introduce well known string for setting the options.
> >
> > Cheers,
> > Rafael
> >
> > _______________________________________________
> > 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/20140820/4b968ecb/attachment.html>