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

Tue Nov 2 20:11:17 PDT 2021

jrtc27 added a comment.

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

> In D96914#3104093 <https://reviews.llvm.org/D96914#3104093>, @jrtc27 wrote:
>
>> In D96914#3098759 <https://reviews.llvm.org/D96914#3098759>, @MaskRay wrote:
>>
>>> In D96914#3098705 <https://reviews.llvm.org/D96914#3098705>, @hvdijk wrote:
>>>
>>>> That followup 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 <https://reviews.llvm.org/rG6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619> gives off the impression that aside from systemd, nothing else would be broken by the change. That is incorrect, enough time has passed since the traditional GNU ld behaviour was ubiquitous that more software has started relying on the new GNU ld behaviour, and lld 13 breaks at least NetworkManager too. (I have reported this to NetworkManager.) What's the right thing to do here?
>>>
>>> Thanks for reporting the bug to NetworkManager.
>>>
>>>> At the very least, I think the release notes simply listing this as an improvement rather than as a breaking change is not enough info for users to beware that their code may need updating, but depending on whether the breakage affects enough other software, maybe it should be reverted on the 13.x branch as well?
>>>
>>> No, I don't think the additional report from NetworkManager is sufficient to justify restoring the GNU ld buggy behavior.
>>
>> It wasn't a bug, it was a feature that you broke.
>>
>>> It's not that many projects depend on the unfortunate behavior and I don't think restoring the behavior now helps any project.
>>
>> It helps all the projects that are broken by this feature they rely on being removed, with no easy way to work around it in some cases.
>
> `-Wl,-z,nostart-stop-gc` is an easy workaround.

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.

>>> Postponing the transition would just cause pain to users of various metadata sections (LLVM PGO).
>>
>> Or you could fix those to be GC-able via some other means.
>
> It cannot. The very problem of the 2015-10 GNU ld behavior is that it essentially makes all metadata sections using C identifier section names not GCable.
> It is a built-in rule which cannot be overridden.

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).

> We could add ad-hoc rules like SHF_GROUP sections could still be GCed. That would help some metadata sections but not others which do not use section groups.
> Section groups have high costs (`sizeof(Elf64_Shdr) = 64`) and may be too expensive to enable.
>
> LDC is even less of a problem because it already needs many changes when importing LLVM changes.
> Well, I have fixed some LLVM upgrade issues for it when I was still using D.

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.

> These projects relying on the post-2015-10 GNU ld behavior. While I feel sympathy for them, I think they should take the oneshot pain.
> The longer we waited, there could just be more problems, and it would be even more difficult to flip the switch.

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.

> From Chrome OS folks I heard that the transition was still quite smooth.
> I think at this point we have mostly passed the finite window of time where problems could have be detected.

ChromeOS is hardly a distribution shipping tens of thousands of packages. It's an OS that's just Chrome, maybe a bit more by now but still fundamentally nothing in comparison to a full FreeBSD or Linux distro.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914