[PATCH] D96914: [ELF] Add -z start-stop-gc to let __start_/__stop_ not retain C identifier name sections

Mon Nov 8 05:29:49 PST 2021

theraven added a comment.

I completely agree with @jrtc27 on this, specifically:

> This is a version lockstep question. How well can an LLD of version X support llvm-project of version Y?

There is *no* dependency between the version of any consumer of the LLVM CodeGen libraries and and a specific linker version, LLVM or otherwise, except in three cases:

- A specific linker version may be unsupported because it has bugs.
- A specific linker version may be the minimum supported version for an opt-in feature in the compiler.
- If doing LTO, LLD must be no older than the compiler (this one falls out from the bitcode compatibility guarantees).

In particular, using LLVM in your compiler front-end does not impose a requirement to use LLD as your system linker.  Historically this was because LLD didn't exist but now it remains an important use case.  Typically, the linker is a global system component for a given target, whereas language front ends may or may not be.  If LLD had to be version locked with clang, rustc, ldc, and every other LLVM-based compiler front end then it would be almost impossible for an LLVM-based compiler ecosystem to exist.  It must be possible to upgrade compilers and link modules generated by the system's C/C++ compiler (which may or may not be clang) using the system's linker (which may or may not be LLD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914