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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 23 11:47:23 PDT 2020


MaskRay added a comment.

In D85994#2350806 <https://reviews.llvm.org/D85994#2350806>, @stefanp wrote:

> In D85994#2350718 <https://reviews.llvm.org/D85994#2350718>, @MaskRay wrote:
>
>> In D85994#2350659 <https://reviews.llvm.org/D85994#2350659>, @stefanp wrote:
>>
>>> @MaskRay 
>>> Sorry... can you pause on this for a second. I want to talk to the `glibc` guys about this first.
>>
>> @stefanp I already did it... I think this is a problem for many ld.so implementations. For example, musl has
>>
>>   if ((def.sym->st_info&0xf) == STT_TLS)
>>            return __tls_get_addr((tls_mod_off_t []){def.dso->tls_id, def.sym->st_value-DTP_OFFSET});
>>
>> It was broken as well...
>
> Can you give me more information about one of these examples?
> I want to try to reproduce this myself and I want to talk to some people on glibc as well. 
> I'm affraid that it is possible to get incorrect code gen in these situations and so I want to try it out myself.
>
> So, what glibc source did you use and how did you compile it?

The simplest example is:

  void __tls_get_addr(void *);
  
  void foo(void *x) {
    __tls_get_addr(x);
  }

dlsym implementations use this snippet to resolve the address of a STT_TLS symbol. You could add a `!config->shared` check but I would be unsure about the whole stuff. The symbol name check is expensive as it applies to every R_PPC64_REL24/R_PPC64_REL24_NOTOC. I think the signal-to-noise ratio for this diagnostic is now low.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85994



More information about the llvm-commits mailing list