Displaying 6 results from an estimated 6 matches for "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 attachm...
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, which...
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
>> mea...
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.