[lld] r302414 - [ELF] - Set DF_STATIC_TLS flag for i386 target.

[George Rimar via llvm-commits]

>>  RelExpr X86TargetInfo::getRelExpr(uint32_t Type, const SymbolBody &S,
>>                                    const uint8_t *Loc) const {
>> +  // There are 4 different TLS variable models with varying degrees of
>> +  // flexibility and performance. LocalExec and InitialExec models are fast but
>> +  // less-flexible models. They cannot be used for dlopen(). If they are in use,
>> +  // we set DF_STATIC_TLS in the ELF header so that the runtime can reject such
>> +  // DSOs.
>> +  if (Type == R_386_TLS_LE || Type == R_386_TLS_LE_32 || Type == R_386_TLS_IE ||
>> +      Type == R_386_TLS_GOTIE)
>> +    Config->HasStaticTlsModel = true;
>
>Have also have to set this for every other architecture we support, no?

Sure. And each such change requires set of testcases.
I started from i386 target. I'll prepare patch for x86_x64 soon.

> Could we do it by looking at RelExpr?

I think no. Problem looking at RelExpr is below. 

Current mapping is:
R_386_TLS_LE->R_TLS
R_386_TLS_LE_32->R_NEG_TLS
R_386_TLS_IE->R_GOT
R_386_TLS_GOTIE->R_GOT_FROM_END

Next relocations shares the same expressions now:
R_386_GOT32->R_GOT, R_GOT_FROM_END
R_386_GOT32X->R_GOT, R_GOT_FROM_END
R_386_GOTOFF->R_GOTREL_FROM_END

So we would probably have a conflict because of shared expressions. 

Also I think looking on expressions does not seem to be
as straightforward as looking on reloc types here, so I would probably not
do that anyways.

> Cheers,
> Rafael