search for: generaldynamictlsmod

Displaying 6 results from an estimated 6 matches for "generaldynamictlsmod".

Did you mean: generaldynamictlsmode
2012 Jun 20
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...ew. Awesome, thanks! I will try to do a more complete review tonight or tomorrow. For now, just two quick observations *) This breaks the clang build, it would be nice to for the first commit to keep the old API. It can be removed as soon as clang is updated. *) Please name the most general model GeneralDynamicTLSMode. Elf's default visibility being called 'default' is already confusing enough :-) I was not sure how hard the first item would be, so I just gave it a try. The resulting patch is attached. > Thanks, > Hans Cheers, Rafael -------------- next part -------------- A non-text attach...
2012 Jun 21
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...s reviewed on cfe-commits), so my plan was just to commit them both at once. 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. > *) Please name the most general model GeneralDynamicTLSMode. Elf's > default visibility being called 'default' is already confusing enough > :-) I was thinking that calling it GeneralDynamicTLSMode wouldn't make sense for non-ELF targets. My thinking was that DefaultTLSModel would mean "use the default model for the target, whic...
2012 Jun 21
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...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 model GeneralDynamicTLSMode. Elf's >> default visibility being called 'default' is already confusing enough >> :-) > > I was thinking that calling it GeneralDynamicTLSMode wouldn't make > sense for non-ELF targets. My thinking was that DefaultTLSModel would > mean "use the default...
2012 Jun 22
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...t; 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. Right. Doing that. >>> *) Please name the most general model GeneralDynamicTLSMode. Elf's >>> default visibility being called 'default' is already confusing enough >>> :-) >> >> I was thinking that calling it GeneralDynamicTLSMode wouldn't make >> sense for non-ELF targets. My thinking was that DefaultTLSModel would >> me...
2012 Jun 20
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
On Fri, Jun 15, 2012 at 9:56 PM, Hans Wennborg <hans at chromium.org> wrote: > (To the list this time..) > > On Fri, Jun 15, 2012 at 7:38 PM, Rafael EspĂ­ndola > <rafael.espindola at gmail.com> wrote: >>> The point still stands, though: that code requires the tls_model >>> attribute to be respected; if the compiler chooses local-exec instead, >>>
2012 Jun 15
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
(To the list this time..) On Fri, Jun 15, 2012 at 7:38 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote: >> The point still stands, though: that code requires the tls_model >> attribute to be respected; if the compiler chooses local-exec instead, >> it won't be dlopen-able. > > This is a fairly contrived use case, and an extension of a gcc extension.