[llvm-commits] [LLVMdev] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)

[Hans Wennborg]

(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.
>
>> I think it adds value to make the behaviour the same as GCC's. And
>> it's not like the difference wouldn't be detectable: the asm is
>> different, the .o files are different, and the code from the non-PIC
>> i386 shared lib example wouldn't load with dlopen.
>
> The gcc behavior is inconsistent with the linker and, as you found
> out, with itself.

Yeah, but I've gotten more attached to the GCC behaviour the more I've
thought about it :/

I respect that you have more experience with both LLVM and the TLS
stuff than me, though :)

> Before you wrote
>
>> I don't have any more compelling reasons than those, and I don't feel
>> super strongly about this, so I'm willing to give in if others
>> disagree with me :)
>
> What about this:
>
> * We implement this first without a 'default' value. This covers the
> one real world use case I know of (libc knowing it is not dlopened).
> * I am to blame if we missed some other use case and commit to
> implementing it in the future if/when it is found :-)

OK, let's give it a couple more days and see if someone else chimes in
or something new comes up. In the meantime, I'll rework the patch the
way you've suggested and if nothing's changed we can land it by the
end of next week. Sounds like a plan?

Thanks,
Hans