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

Harald van Dijk via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 8 16:28:07 PST 2021


hvdijk added a comment.

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.

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

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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96914



More information about the llvm-commits mailing list