[PATCH] D85994: [LLD][PowerPC] Add check in LLD to produce an error for missing TLSGD/TLSLD
Stefan Pintilie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 23 10:19:50 PDT 2020
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
More information about the llvm-commits
mailing list