[PATCH] D85994: [LLD][PowerPC] Add check in LLD to produce an error for missing TLSGD/TLSLD

[Stefan Pintilie via Phabricator via llvm-commits]

stefanp added a comment.

In D85994#2350431 <https://reviews.llvm.org/D85994#2350431>, @MaskRay wrote:

> In D85994#2219062 <https://reviews.llvm.org/D85994#2219062>, @MaskRay wrote:
>
>> First, if this issue is not common enough, I'd rather we don't have a diagnostic at all.
>>
>> If we do need it, note that `*(i - 2);` may be out of bounds.
>>
>> Last, we should avoid pre-built object files. You can synthesize them with yaml2obj. The preferred style is `llvm/test/tools/llvm-readobj/ELF/*.test`. lld/test/ELF has some yaml2obj tests as well.
>
> @stefanp The error turns out to be a problem when building glibc.
>
> elf/dl-sym.c has a raw `__tls_get_addr` call (it sets up the parameter by itself), without R_PPC64_TLSGD/R_PPC64_TLSLD (similar to `CallOnly`). Shall we drop the logic? I believe GNU ld does not have the logic.
>
>   /* Return the symbol address given the map of the module it is in and
>      the symbol record.  This is used in dl-sym.c.  */
>   static void *
>   _dl_tls_symaddr (struct link_map *map, const ElfW(Sym) *ref)
>   {
>   # ifndef DONT_USE_TLS_INDEX
>     tls_index tmp =
>       {
>         .ti_module = map->l_tls_modid,
>         .ti_offset = ref->st_value
>       };
>   
>     return __TLS_GET_ADDR (&tmp);
>   # else
>     return __TLS_GET_ADDR (map->l_tls_modid, ref->st_value);
>   # endif
>   }
>   #endif

I didn't realize that this was possible.
The problem is that now we can get silently bad code. But I guess it's the user that needs to watch out for problems.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85994/new/

https://reviews.llvm.org/D85994