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

[Jessica Clarke via Phabricator via llvm-commits]

jrtc27 added a comment.

In D96914#3110224 <https://reviews.llvm.org/D96914#3110224>, @MaskRay wrote:

> In D96914#3110015 <https://reviews.llvm.org/D96914#3110015>, @jrtc27 wrote:
>
>> In D96914#3109977 <https://reviews.llvm.org/D96914#3109977>, @MaskRay wrote:
>>
>>> Mach-O ld64 uses the same model as current ld.lld -z start-stop-gc.
>>
>> This isn't relevant. I am not objecting to the semantics, I am objecting to the *timeline* for the *change* in semantics. Mach-O has always (I assume) had those semantics, and had ways to deal with them. The ways to deal with them for ELF and the change in semantics happened back-to-back, rather than introducing the mechanism for explicitly retaining the sections but keeping the old default for several years so that when you come time to change the default there are no issues with assuming the mechanism to retain the sections exists. I feel like a broken record repeating this but you don't seem to acknowledge this as being my complaint so I have to keep telling you why your characterisation of my objection is inaccurate.
>
> I kept repeating because FreeBSD' ldc usage is on the edge of what I consider supported interfaces.
> In other ways, even if it is supported, I think it is barely.
>
> This is a version lockstep question. How well can an LLD of version X support llvm-project of version Y?
>
> When X is smaller than Y, it is largely considered "may not work". That's why asan/etc can use SHF_LINK_ORDER before the features are well ready. LTO for this case definitely can't work.
>
> When X is larger than Y, for regular object files, this is "usually should work unless Y is too small".
> When X is compiler-rt instead of LLD, this is outright "unsupported". We have such a large expectation on the linker because that is our expectation for ABI and how compilers/linkers collaborate.
> The ldc usage somewhat sits between regular object file and LTO to me, even though it does just plain regular object file generation.
>
> I agree that I failed to consider the llvm-project<13 and LLD>=13.0.0 situation and I apologized for the trouble.
> That said, I think the blast radius is small:
>
> - llvm-project<13 and LLD>=13.0.0 is uncommon
> - C identifier name sections usage is minor
> - ldc uses newish GNU ld feature which is not a traditional behavior.
> - ldc has existing code disabling `--gc-sections` for PGO.
> - ldc has LDC_WITH_LLD. If it wants to use LTO, bundling lld and probably considering LLD is the way forward.
> - In https://github.com/ldc-developers/ldc/issues/3861, I have listed many ways FreeBSD folks can move forward.
>
> Again, the window of time with potentially problems is finite and evidences from some large LLD adopters show that we've mostly moved outside the period.
> With these new large adopters using the new behavior (actually traditional behavior and Mach-O's behavior), we can mostly make ensure that such future brittle dependency on our "weak support interfaces" will very unlikely happen.

I do not think your opinion is shared with other LLVM developers. It's extremely common for compilers to use an older version of libLLVM; look at Rust, GHC, LDC, Gollvm, they all tend to lag in updating to newer libLLVM versions. LLD and LLVM live in the same repository under the llvm-project umbrella, but there is absolutely no reason why they should be tied to one another; the interface between .o files and the linker is supposed to be stable. Moreover, the fact that LDC uses libLLVM is an implementation detail (albeit in the name); it really should not matter how the compiler generates object files, it could be via libLLVM, libgccjit, printing textual assembly fed into the system assembler or some hand-rolled code emitter, it does not change the situation that changing the semantics of the linker breaks any existing compilers, whatever way they generate code. All of those cases are broken unless the projects in question have (a) updated to use SHF_GNU_RETAIN and/or -z no-start-stop-gc (b) dropped compatibility with pre-2020/1 linkers due to using SHF_GNU_RETAIN and/or -z no-start-stop-gc (or added ugly code to do run-time detection of the linker that has previously not been required due to actually maintaining a stable interface between compiler and linker, only breaking that interface in a very gradual, carefully-planned manner). So no, this argument is highly flawed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914