[PATCH] D70398: [lld] Support copy relocations for TLS symbols

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D70398#1755440 <https://reviews.llvm.org/D70398#1755440>, @jrtc27 wrote:

> I think the fact that many runtime linkers out there don't handle it correctly is a pretty compelling reason in and of itself (but I agree that, being a new ABI, it should avoid introducing more copy relocations). The fact that GCC relies on this behaviour (which glibc and bfd correctly implement) but doesn't document it anywhere other than in the compiler source itself is worrying, since it leads to the situation we have now where binaries built by GCC+bfd for other systems (such as FreeBSD) may not run correctly, as they will copy garbage from early on in the mapping.


I am also worried about defects in fait accomplis. (I can regret nothing but I didn't start watching RISC-V toolchain development earlier...) This issue has demonstrated again how an alternative implementation (libc, compiler, linker, binary utilities, etc) can be valuable by improving the design!

> EDIT: I see the discussion linked by MaskRay has already reached the conclusion that GCC will stop emitting these. I will file a patch for LLVM to do the same if nobody beats me to it (relaxations can come later once they are finalised).

I wanted to do this, but you claimed this first. Go ahead:) Given the consensus that TLS copy relocation is a bad idea and newer toolchains do not need to support it, can be drop this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70398