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

Tue Nov 2 20:51:50 PDT 2021

MaskRay added a comment.

> Not if you're in code that doesn't know what linker, let alone the version of it, is being used. If you don't use it for new LLD you break because your sections are bogusly GC'ed. If you use it for old LLD or BFD you break because the option doesn't exist and gives an error. Even Clang's driver can't know if the option is supported, so how do you expect other projects using similar code (like LDC) to do so? Just because you can detect the linker at toolchain build time doesn't mean you know what linker will be used at toolchain run time.

I don't understand why this is a problem.
The code doesn't need to dispatch on different behaviors.
It just needs to be written in a way portable to pre-2015-10 GNU ld and current LLD.

If it needs time for transition, `-Wl,-z,nostart-stop-gc` in a configure time detection.

> Sure you can. If you can add SHF_GNU_RETAIN, you can add SHF_GNU_IT_IS_SAFE_TO_GC_ME. Or you can do a proper transition (see below).

Since there is a section flag with the positive semantics, there is zero chance the flag with the negative semantics would be accepted.
The name also looks irony, rather than a real proposal.

> That is irrelevant. This is not about what libLLVM version it links against. This is about what the system linker is, which could be BFD, gold or LLD, and has zero connection to the libLLVM version used.

My point is that every time they upgrade llvm-project, they already need to deal with changes.
As experienced toolchain developers they are in a better position detecting and fixing the issues.
If you find a https://github.com/ldc-developers/ldc issue, the more productive way is to open an issue there.

> This is not how you do a transition. You do a transition by adding the option, then _several years later_ flipping the default so that it can just be assumed to exist. You _can't_ add the option and flip the default _in the same release cycle_, that leads to a mess.

Not for this case. For this case fixing early can make sure the whole ecosystem takes the least pain.
FWIW I still don't see why it is a mess. It it an easy case dispatching on the availability of the option, (slightly worse) dispatching on LLD version.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914