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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

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.

>> The way ldc uses `__start___minfo` is also incompatible with GNU ld 2015-10.
>
> Which was deemed a bug in GNU ld, and got fixed. There have been bugs in its --gc-sections implementation over the years that got fixed, that doesn't mean everything that didn't used to work is regarded as something you shouldn't do.
>
>> There are several ways to make FreeBSD work.
>>
>> Finally, as I mentioned in the ldc issue, the llvm-project<13.0.0 and ld.lld>=13.0.0 is not supported way using LTO (probably weaker than "unsupported").
>
> I don't know why you're talking about LTO all of a sudden, we've been talking about using ld.lld --gc-sections on plain already-compiled-to-machine-code .o files, no LTO in sight (well, GC'ing sections is _technically_ optimisation done at link time, but so are all manner of things linkers do, and they're not what people mean by LTO).




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914