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

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Wed May 10 06:39:21 PDT 2017


George Rimar <grimar at accesssoftek.com> writes:

>>>  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.

Thanks.

>> 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.

But if you check inside handleTlsRelocation there is no ambiguity. If we
can avoid having to add a check for every architecture that would be an
improvement.

Cheers,
Rafael


More information about the llvm-commits mailing list