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

Mon Nov 8 17:01:48 PST 2021

MaskRay added a comment.

In D96914#3117003 <https://reviews.llvm.org/D96914#3117003>, @hvdijk wrote:

> In D96914#3115988 <https://reviews.llvm.org/D96914#3115988>, @MaskRay wrote:
>
>> In D96914#3115794 <https://reviews.llvm.org/D96914#3115794>, @tstellar wrote:
>>
>>> What are the downsides of reverting 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 <https://reviews.llvm.org/rG6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619> ?
>>
>> @tstellar Various metadata section users will get affected because they will see unneeded size increase.
>> Such users typically use Clang solely and use the main branch so if you keep the revert to release/13.x branch, that'll be fine.
>
> If we revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 <https://reviews.llvm.org/rG6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619> on main as well, such users will be able to explicitly add `-z start-stop-gc` to their linker options to reduce the size again; that change would stay in. In my opinion, adding that option is something that would be good for them to do regardless of which direction LLD takes, because they cannot rely on it being the default as long as other linkers are in widespread use where that is not the default. As far as I can tell, GNU have not changed their default, they default to `-z nostart-stop-gc`, and in your report to them (https://sourceware.org/bugzilla/show_bug.cgi?id=27451) you suggested that they may never want to change that default.

The revert-on-main choice would place the burden on the wrong side. Many llvm-project users solely use LLD.
"Making LLD links better while making GNU ld correct but not optimal" is better than "making LLD links suffer the same way as GNU ld>=2015-10".

>> Another disadvantage is that more software can incorrectly leverage the `-z nostart-stop-gc` behavior before LLD 14.0.0 comes out. There is a risk dealing with more software for LLD 14.0.0.
>
> As has been mentioned earlier, whether such use is incorrect is one of the things not everybody here agrees on, but otherwise this is true, there is a chance that more software will be released that will require changes to work as intended under `-z start-stop-gc`.
>
>> People objecting here neglected the point that the GNU ld behavior was also new 2015-10.
>> Its traditional behavior was the same as the `-z start-stop-gc` default.
>
> The original GNU ld behaviour was regarded by them as a bug, it broke software, and fixing that bug was a relatively safe change: *not* removing sections when they could be removed tends to only increase size, doing no harm otherwise.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=11133
> https://sourceware.org/bugzilla/show_bug.cgi?id=19161
> https://sourceware.org/bugzilla/show_bug.cgi?id=19167
>
> You may disagree on whether they were correct to classify it as a bug, but given that their developers considered it as such, it seems perfectly reasonable to me for other developers to take them at their word that the new behaviour was intentional and something users can rely on.

I didn't want to reference binutils folks' names directly :(
Alan Modra considered the traditional GNU ld behavior correct in 2011.
One user who was involved in the discussion made gold to use the `-z nostart-stop-gc` behavior but did not think hard about potential size problems.
HJ Lu went ahead and implemented the `-z nostart-stop-gc` behavior but he did not notice that the conservative behavior could make metadata section GC unfortunate and (eventually) enabled the current `-z nostart-stop-gc` behavior in 2015-10 (there was an attempt in 2011 but that did not appear to work).

If we take into account the ld64 behavior, it is probably more obvious that the 2015-10 GNU ld change was problematic.

>> @theraven My point is based on many conditions: the adoption of the C identifier name section, how likely the 2015-10 GNU ld behavior may be exploited by newer software, the GNU ld traditional behavior, Mach-O ld64 behavior, how likely people use llvm-project<13.0.0 library with 13.0.0 system linker, whether the symptom has good discoverability and workarounds, etc.
>> It's not that I think we should have an unneeded "version lockstep".
>>
>> That said, I have spent so many hours on what I could use for more productive things. I have also got tired on some hostile comments.
>
> Please understand that I have no interest in having such a long discussion myself. But, we're in a lousy situation where things are broken, I saw no good way out of that other than by reverting your commit, and although your comments suggest you do, I am not seeing how, so the only choices I have are just reverting your change unilaterally (which is obviously a bad idea) or continuing this discussion.
>
> As for the tone, if this is also referring to me and this is something you would like to discuss, feel free to reach out privately.
>
> Note that I now do see a possible third option though, depending on whether other people are willing to help: we could make the default linker behaviour a CMake option defaulting to the current GNU behaviour, and once we have that CMake option and get it into a release, work with a distro to do a mass rebuild with LLD with the default flipped, see what is still broken and take it from there.

This is an option, but I have mentioned many times that I think the blast radius is small and adding more complexity would not be justified.
If making such a change specifically for FreeBSD can help me, I am open to helping them, but I think the change is so trivial that they can handle it by themselves.

I have asked many folks and believe that GCC plus system LLD is very uncommon.
You seemed to imply that your distro (but didn't mention it) uses such a configuration.
I'd be reluctant but can afford adding such a CMake option as I think the utility of such an option would be low.

There is a fourth option. FreeBSD can cherry pick 47c5576d7d586624c38f76bd3168e05f6ef1f838 <https://reviews.llvm.org/rG47c5576d7d586624c38f76bd3168e05f6ef1f838> to their 12.0.* package.
`llvm.used` will use `SHF_GNU_RETAIN` and it will work with current `-z start-stop-gc` behavior.
That will fix ldc and any LLVM IR producers folks might be concerned with. (Again: I think the utility would be low).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914