[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