search for: generaldynamictlsmodel

...> what they have (macho has only default and hidden I think). > > It should at least be self consistent I think. I am ok with 4 llvm > specific names or using the 4 names used by the tlf.pdf document. Just > make sure none of them is named 'default' :-) OK, let's go with GeneralDynamicTLSModel then. > +   separated copy of the variable). Optionally, a suggested TLS model may be > > Not sure I would call it "suggested". What it is is a promise by the > FE/user that some restrictions apply to how the variable is used: > > * localdynamic: Only used from this DSO...

> If we don't want to do that, I think we should try to add the new > constructors while keeping the old ones around, and then delete the > old constructors once clang is updated. Yes, this would probably be the best. To make clang build I just hacked the constructors in the patch I posted, but they should really just forward to the new ones. >> *) Please name the most general

...but doesn't have external or weak linkage! i8** @myvar This is how I create the GlobalVariable: ------------------------------------------------ new llvm::GlobalVariable(*M, IRB.getInt8PtrTy(), false, llvm::GlobalValue::CommonLinkage, nullptr, "myvar", NULL, GlobalVariable::GeneralDynamicTLSModel, 0, false); ------------------------------------------------ I am using "IRB.getInt8PtrTy()" because this variable will be a pointer to a buffer "char *". This used to work with Clang 4.0, I have been trying to port the pass to trunk. Did something changed and it's nec...

> OK, let's go with GeneralDynamicTLSModel then. OK >> The restrictions should be documented too. > > I'm not sure how much detail we should go into here, because the > restrictions might vary depending on the environment. For example, > with glibc, it will be possible to use initial-exec in a .so that will > be l...