[lld][CMake] Add LLD_DEFAULT_NOSTART_STOP_GC

[MaskRay]

Summary

This option is for groups who need time to accomodate the ld.lld -z
start-stop-gc default.

This is off by default because we don't have evidence that many groups
will need default -z nostart-stop-gc. Many groups are fine with the -z
start-stop-gc default (matching GNU ld<2015-10): Android, Chrome OS
(Linux), Fuchsia, Google, Meta, SN systems, some Gentoo Linux users I
asked using -fuse-ld=lld (with or without using Clang), all gn build
users, all Bazel build users. A FreeBSD exp-run exposed just one broken
package (ldc) with 3 packages using it
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260159).
-z nostart-stop-gc default matches ld64 behavior for section$start
symbols and encourages in-tree and out-tree developers to think about
section based linker garbage collection prudently.

[hvdijk]

@tstellar Apologies, but I had very intentionally not reviewed this. This patch was misleadingly presented as doing what you had asked when it does the opposite (note the edit history on https://reviews.llvm.org/D96914#3141049, the author is perfectly aware that this is opt-out, not opt-in, but presents it as opt-in anyway), and was accompanied by an insult. I don't think there's actually any point in trying to engaging constructively here, the author is engaging in malicious behaviour and as long as that continues the technical aspects are irrelevant.

[MaskRay]

IIRC the edit history is about opting out the -z start-stop-gc => opting in the -z nostart-stop-gc, or just because I made a typo.
I edited it because with the presence of negative meaning option (nostart-stop-gc), opt-out/opt-in can be ambiguous.

You never provide sufficient evidence to justify the -z nostart-stop-gc default.

Well, I can provide evidence why the -z start-stop-gc behavior (7 months in origin/main now, matching GNU ld<2015-10) sticks:

There are anecdotal or non-anecdotal evidences that many groups are fine with the -z start-stop-gc default (matching GNU ld<2015-10): Android, Chrome OS (Linux), Fuchsia, Google, Meta, SN systems, some Gentoo Linux users I asked using -fuse-ld=lld (with or without using Clang), all gn build users, all Bazel build users.

This patch was misleadingly presented as doing what you had asked when it does the opposite

I don't think it is misleading. I disagree with your claim about the -z nostart-stop-gc default. You can find my previous replies: it's all the same standpoint.
I did want to pull myself out of the needless discussion at one point (that's when I said I was fine with -z start-stop-gc in 13.* default).
Since you never listen to others, so you think it is misleading.

If you use words like "malicious", I don't think we can have constructive discussions, either.
It's so bad waste of my time.

[tstellar]

@MaskRay This patch needs to change the default behavior to what it was prior to 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619. It does not look to me like the patch does this. If I am wrong, please explain why.

We've been discussing this for too long already and need a conclusion. In the release/13.x, I'm planning to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 since we don't have any other proposed fix.

If we can't get a compromise patch approved by Thursday, I'm going to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 in main too. As I mentioned on the other thread, the idea behind 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 was NAK'd, but it was committed anyway. We need to follow community process around code review and revert back to the original behavior and then discuss the next steps afterwards.

[MaskRay]

In D114186#3159389, @tstellar wrote:

@MaskRay This patch needs to change the default behavior to what it was prior to 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619. It does not look to me like the patch does this. If I am wrong, please explain why.

We've been discussing this for too long already and need a conclusion. In the release/13.x, I'm planning to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 since we don't have any other proposed fix.

The conclusion is that FreeBSD has taken care of this, or at least, I don't think 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 would cause lasting harm to them.

I have repeatedly explained that the issue is specific to very few packages (some Gentoo GCC/Clang -fuse-ld=lld 13.0.0 folks told me their system works fine; well, I'd be happy to know if they could find another package (like ldc) which will have the similar problem)
If FreeBSD does want to be conservative, they can either add -z start-stop-gc to their system, as @emaste told me in ~April, or apply this CMake patch to their ports and set the CMake variable.

Reverting 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 would cause lasting harm to instrumentation users.

If we can't get a compromise patch approved by Thursday, I'm going to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 in main too. As I mentioned on the other thread, the idea behind 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 was NAK'd, but it was committed anyway. We need to follow community process around code review and revert back to the original behavior and then discuss the next steps afterwards.

I think you missed many replies from me explaining why reverting the 7-month old change would not do anything good. I humbly beg that you read my replies.

---

You know that I am opinionated. Sorry that I am making judgement as a non-distro-affiliated person: the few Gentoo users and the wider ChromeOS, I think -z start-stop-gc default has been fine.
If hvdijk challenge the decision, provide more clue (as I requested many times in the other thread).

[MaskRay]

If we can't get a compromise patch approved by Thursday,

According to hvdijk's previous unacceptable wording to me, I think they are in a hatred mode. So I don't think I can get this approved by them.

[tstellar]

In D114186#3159453, @MaskRay wrote:

In D114186#3159389, @tstellar wrote:

@MaskRay This patch needs to change the default behavior to what it was prior to 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619. It does not look to me like the patch does this. If I am wrong, please explain why.

We've been discussing this for too long already and need a conclusion. In the release/13.x, I'm planning to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 since we don't have any other proposed fix.

The conclusion is that FreeBSD has taken care of this, or at least, I don't think 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 would cause lasting harm to them.

I have repeatedly explained that the issue is specific to very few packages (some Gentoo GCC/Clang -fuse-ld=lld 13.0.0 folks told me their system works fine; well, I'd be happy to know if they could find another package (like ldc) which will have the similar problem)
If FreeBSD does want to be conservative, they can either add -z start-stop-gc to their system, as @emaste told me in ~April, or apply this CMake patch to their ports and set the CMake variable.

Reverting 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 would cause lasting harm to instrumentation users.

If we can't get a compromise patch approved by Thursday, I'm going to revert 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 in main too. As I mentioned on the other thread, the idea behind 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 was NAK'd, but it was committed anyway. We need to follow community process around code review and revert back to the original behavior and then discuss the next steps afterwards.

I think you missed many replies from me explaining why reverting the 7-month old change would not do anything good. Please read my replies.

I'm asking for the behavior to be changed back, because 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 goes against the LLVM developer policy. If you want to make a technical argument about why 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 should stay in, then you need to convince @jrtc27 and others who object to this change to drop their objections and state that on one of the reviews.

[MaskRay]

In D114186#3159538, @tstellar wrote:

I'm asking for the behavior to be changed back, because 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 goes against the LLVM developer policy. If you want to make a technical argument about why 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 should stay in, then you need to convince @jrtc27 and others who object to this change to drop their objections and state that on one of the reviews.

@tstellar This claim will harm my fame so I have to defend.

bd1976llvm gave me this in April:
"Thanks for the warning about changing the default to -z start-stop-gc. I have read your excellent blog entry explaining about it 🙂 This doesn't seem to cause any problems with the test code I have. I think we are pretty happy with the change given that we can offer work-arounds in the rare case that any games are affected. If we find any interesting problems caused by -z start-stop-gc I will let you know."
Then-Facebook was informed in February.
@dim and @emaste were informed in March 1. The initial message I sent to them used "In a future release" not saying 13.0.0 was my mistake. And giving a second-round heads-up when the change was pushed was my mistake, too.

As a hindsight, it'd be much better if I created a patch CCing all the relevant folks, and I screwed up something (and clearly failed on ldc/NetworkManager) but I don't necessarily agree with your LLVM developer policy claim.

---

For origin/release/13.x you have the final discretion. I just want to repeat that some distributions have built lld 13.0.0 for more than one month now and Gentoo Linux users doing (GCC/Clang LDFLAGS=-fuse-ld=lld) is fine.

For origin/main I request higher standard for a revert. They need to provide more evidence. We should all keep in mind that the commit has been there fore 7 months and rolling release users have been well served.
(I may not be around on Thursday/Friday.)

If that is still not sufficient, I created D114830 to give the user more hints.

To be honest I think this CMake change unnecessary and I hope we can avoid it for origin/main.

[tstellar]

In D114186#3162948, @MaskRay wrote:

In D114186#3159538, @tstellar wrote:

I'm asking for the behavior to be changed back, because 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 goes against the LLVM developer policy. If you want to make a technical argument about why 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 should stay in, then you need to convince @jrtc27 and others who object to this change to drop their objections and state that on one of the reviews.

@tstellar This claim will harm my fame so I have to defend.

bd1976llvm gave me this in April:
"Thanks for the warning about changing the default to -z start-stop-gc. I have read your excellent blog entry explaining about it 🙂 This doesn't seem to cause any problems with the test code I have. I think we are pretty happy with the change given that we can offer work-arounds in the rare case that any games are affected. If we find any interesting problems caused by -z start-stop-gc I will let you know."
Then-Facebook was informed in February.
@dim and @emaste were informed in March 1. The initial message I sent to them used "In a future release" not saying 13.0.0 was my mistake. And giving a second-round heads-up when the change was pushed was my mistake, too.

As a hindsight, it'd be much better if I created a patch CCing all the relevant folks, and I screwed up something (and clearly failed on ldc/NetworkManager) but I don't necessarily agree with your LLVM developer policy claim.

Here is why I think that 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 goes against the LLVM Developer Policy:

• @jrtc27 Approved D96914 on the condition that the behavior be opt-in only. https://reviews.llvm.org/D96914#2586099
• The behavior was changed from opt-in only to on by default in 6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619 which was committed without public review.

To me this is equivalent to committing a patch that has been NAK'd by someone, which is against the Developer Policy, and is usually fixed by reverting the affected patch.

I am not accusing you of doing anything malicious, it looks like it was just an oversight, which happens, I get that, especially since it's clear you reached out to other users who may be affected to make sure they were OK with the change. However, I would really like to see some kind of resolution here that everyone can agree on. It appears to me like the people objecting to this change have just given up, which is too bad. It would probably help if someone more familiar with the technical details got involved to help mediate the discussion. I really don't understand the technical details here. I just want to make sure the Developer Policy is followed and we don't end up alienating members of the community by making them feel like their feedback doesn't matter.

[emaste]

compatible with GNU ld newer than 2015-10

I do not understand this comment - FreeBSD used an ancient version of GNU ld (2.17.50, from mid 2000s) until we migrated all target architectures to lld. That old ld defaults to no GC start/stop, we have been using that behaviour for decades.

In any case, I do not think LLD_DEFAULT_NOSTART_STOP_GCis a solution to this general issue for FreeBSD. For the base system it doesn't really matter -- we can easily add -z no-start-stop-gc or whatever to default build flags. The concern is with third party software in the ports collection, for which we have found several instances. Those are probably not FreeBSD-specific issues, and will likely occur on any system using lld as the linker. Are there other projects that (a) use lld as the system or default linker and (b) build 30000+ different third party software packages?

[emaste]

FreeBSD used an ancient version of GNU ld (2.17.50, from mid 2000s) until we migrated all target architectures to lld. That old ld defaults to no GC start/stop, we have been using that behaviour for decades.

Oh, wait - I'm mistaken here, the old base system use was without --gc-sections.

Using the example from GNU ld PR 19167 on FreeBSD 11 with GNU ld 2.17.50:

% ld --gc-sections -o x a.o b.o
a.o: In function `_start':
(.text+0x0): undefined reference to `__start__foo'

[MaskRay]

I had a long chat with @emaste in IRC today.

The evidence I showed includes (the paragraph I am writing below is more detailed):

• https://codesearch.debian.net/search?q=extern.*__stop_.*%5C%5B%5C%5D&literal=0 Only ~20 packages use __stop_. Some are duplicates. Most don't use -Wl,--gc-sections in their build system. Some definitely work well now (glibc,binutils,ell,iwd). Many are quite old and existed before GNU ld's 2015-10 switch. They worked with traditional GNU ld and should work with current ld.lld.
• Some distros have tested for quite some time now (ChromeOS, some rolling release toolchain users (speculating: some companies, some projects with tighter connection with llvm-project)). Gentoo Linux got the 13.0.0 package since 2021-10-01. Gentoo has both Clang -fuse-ld=lld and GCC -fuse-ld=lld users.

@jrtc27 and @emaste are both on board that the traditional GNU ld behavior / current 13.0.0 behavior is the future. The transition plan was important and that was in the cracks (sorry!).

We cannot change 13.0.0 now. For origin/main, you may decide to change it, but hope after some justification (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260159).
(if any, maybe a matter of adding -z nostart-stop-gc).
For 13.0.1, you have decision. Though hope my analysis can help you understand the low probability of risk (while a compiler upgrade may deal with 30000+ packages. The behavior deals with maybe 20 or fewer.)

I worry that switching the origin/main default back to -z nostart-stop-gc can stimulate new regressions, e.g.

• ldc (compiler), regression in 2016
• Linux kernel has a config CONFIG_LD_DEAD_CODE_DATA_ELIMINATION for --gc-sections. It does not work for many cases yet, but I hope contributors don't cause new regressions. There are quite few users of origin/main ld.lld.

To add more helpers, we have D114830 (which will be nice in 13.0.1). With this users will clearly know what to do.

[emaste]

@jrtc27 and @emaste are both on board that the traditional GNU ld behavior / current 13.0.0 behavior is the future.

I'm not sure if Jessica weighed in on this or not. I can confirm that after discussion and thinking about it I do think start-stop-gc is the appropriate end state.

[jrtc27]

In D114186#3167955, @emaste wrote:

@jrtc27 and @emaste are both on board that the traditional GNU ld behavior / current 13.0.0 behavior is the future.

I'm not sure if Jessica weighed in on this or not. I can confirm that after discussion and thinking about it I do think start-stop-gc is the appropriate end state.

I've tried to stay out of this for my own sanity, but my objection has not been about the end state which, in a world where SHF_GNU_RETAIN can be relied upon to work, is a more sensible state than historically (I would've preferred that uses that wanted the new GC behaviour use a new way of doing things rather than repurposing something that didn't do the right thing and then forcing their needs on it, breaking existing uses, but I can see and appreciate the technical reasons for doing it this way, and ignoring compatibility issues it does make more sense). My objection has been that SHF_GNU_RETAIN is not ubiquitous enough, both in terms of support and use, for the default start-stop-gc behaviour to have been changed.

[dim]

In D114186#3167979, @jrtc27 wrote:

I've tried to stay out of this for my own sanity, but my objection has not been about the end state which, in a world where SHF_GNU_RETAIN can be relied upon to work, is a more sensible state than historically (I would've preferred that uses that wanted the new GC behaviour use a new way of doing things rather than repurposing something that didn't do the right thing and then forcing their needs on it, breaking existing uses, but I can see and appreciate the technical reasons for doing it this way, and ignoring compatibility issues it does make more sense). My objection has been that SHF_GNU_RETAIN is not ubiquitous enough, both in terms of support and use, for the default start-stop-gc behaviour to have been changed.

I agree that that is the main reason for making start-stop-gc not the default *yet*. But what is the criterion for having "enough" SHF_GNU_RETAIN support? In the llvm/clang world you typically upgrade the compiler and linker at the same time, so as long as clang supports SHF_GNU_RETAIN *now* it should be okay for that part.

But what about third parties like gcc, dlang, etc? When will we consider them to be sufficiently up-to-date with regards to retain attributes?

[jrtc27]

In D114186#3168029, @dim wrote:

In D114186#3167979, @jrtc27 wrote:

I've tried to stay out of this for my own sanity, but my objection has not been about the end state which, in a world where SHF_GNU_RETAIN can be relied upon to work, is a more sensible state than historically (I would've preferred that uses that wanted the new GC behaviour use a new way of doing things rather than repurposing something that didn't do the right thing and then forcing their needs on it, breaking existing uses, but I can see and appreciate the technical reasons for doing it this way, and ignoring compatibility issues it does make more sense). My objection has been that SHF_GNU_RETAIN is not ubiquitous enough, both in terms of support and use, for the default start-stop-gc behaviour to have been changed.

I agree that that is the main reason for making start-stop-gc not the default *yet*. But what is the criterion for having "enough" SHF_GNU_RETAIN support? In the llvm/clang world you typically upgrade the compiler and linker at the same time, so as long as clang supports SHF_GNU_RETAIN *now* it should be okay for that part.

But what about third parties like gcc, dlang, etc? When will we consider them to be sufficiently up-to-date with regards to retain attributes?

For this kind of change, where some software will end up having to bump its minimum dependency versions (like ldc, so it can either use a libLLVM that supports SHF_GNU_RETAIN or pass -z nostart-stop-gc to lld), I would normally say two years since the features needed for software to continue working were landed, as that's the usual release cycle cadence for major Linux distributions (or LTS versions if they have interim releases), since otherwise there won't be a(n LTS) release of a given distro that is able to satisfy the updated dependency requirements. If all the issues with flipping the default get resolved before then in ways that don't require bumping dependencies (though I don't currently see how the latter can be true) then great, it can be shorter.

[MaskRay]

In D114186#3168048, @jrtc27 wrote:

In D114186#3168029, @dim wrote:

In D114186#3167979, @jrtc27 wrote:

I've tried to stay out of this for my own sanity, but my objection has not been about the end state which, in a world where SHF_GNU_RETAIN can be relied upon to work, is a more sensible state than historically (I would've preferred that uses that wanted the new GC behaviour use a new way of doing things rather than repurposing something that didn't do the right thing and then forcing their needs on it, breaking existing uses, but I can see and appreciate the technical reasons for doing it this way, and ignoring compatibility issues it does make more sense). My objection has been that SHF_GNU_RETAIN is not ubiquitous enough, both in terms of support and use, for the default start-stop-gc behaviour to have been changed.

I agree that that is the main reason for making start-stop-gc not the default *yet*. But what is the criterion for having "enough" SHF_GNU_RETAIN support? In the llvm/clang world you typically upgrade the compiler and linker at the same time, so as long as clang supports SHF_GNU_RETAIN *now* it should be okay for that part.

But what about third parties like gcc, dlang, etc? When will we consider them to be sufficiently up-to-date with regards to retain attributes?

For this kind of change, where some software will end up having to bump its minimum dependency versions (like ldc, so it can either use a libLLVM that supports SHF_GNU_RETAIN or pass -z nostart-stop-gc to lld), I would normally say two years since the features needed for software to continue working were landed, as that's the usual release cycle cadence for major Linux distributions (or LTS versions if they have interim releases), since otherwise there won't be a(n LTS) release of a given distro that is able to satisfy the updated dependency requirements. If all the issues with flipping the default get resolved before then in ways that don't require bumping dependencies (though I don't currently see how the latter can be true) then great, it can be shorter.

A toolchain release may contain bugfixes which can cause software to break if they happen to rely on the buggy behavior.
We fix many bugs without introducing a mechanism to go back to the original state. (See below, it's all about the potentially affected packages.)
In this case it is probably unfair to say software relying on the __start_ GC behavior has a bug because the ELF world for a long term does not provide good facility (no good != not-exist) for marking sections.
But it is fair to say they are not written with -Wl,--gc-sections in mind.

Using -Wl,--gc-sections for the unprepared software started to work with GNU ld>2015-10. I'll say that is by accident.
-Wl,--gc-sections is uncommon (no distro enabled it by default), so historically there is no problem.
(The addition of retain will make this more reliable, but it is no mandatory.)

Whether the default can flip and how soon it can flip, depend on the number of software relying on the accidental behavior, how they can cover from the regression, how serious the regression will be.
From Debian Code Search, I'll say the number is small (~20 even after counting duplicates).
I have checked many and all I checked don't have internal -Wl,--gc-sections.

With -z nostart-stop-gc, I'll say it is easy for them to recover from the regression.
With the introduction of a diagnostic and a new documentation page, I'll say it is straightforward for a developer/user to catch the problem.

With these, I think keeping -z start-stop-gc for 13.0.1 is still fine.
Some people tend to be more conservative and don't agree with me, but on the other hand cannot show more evidence.
With other points (e.g. at this point, flipping the behavior back and forth can probably just lead to confusion since people may not remember why 13.0.0/13.0.1/main are different. 13.0.0 cannot be changed now.)

https://lld.llvm.org/ELF/start-stop-gc is available now. We can flesh out the content if needed. (The diagnostic line has a typo of the URI, for example.)

[emaste]

We requested an experimental ports build with the start-stop-gc behaviour reverted (i.e., with getZFlag(args, "start-stop-gc", "nostart-stop-gc", false);)

The following previously-failing packages appear to be fixed by the change:

• igv-2.9.4
• firebird25-client-2.5.9_1
• dub-1.14.0
• ghidra-9.1
• apache-openoffice-4.1.11
• apache-openoffice-devel-4.2.1633255994,4
• pioneer-20210723_1
• signald-0.15.0
• onedrive-2.4.12
• keepass-2.46
• reptyr-0.8.0
• gtk-sharp-beans-2.14.1_1
• gtkd-3.9.0

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260159

[MaskRay]

In D114186#3173840, @emaste wrote:

We requested an experimental ports build with the start-stop-gc behaviour reverted (i.e., with getZFlag(args, "start-stop-gc", "nostart-stop-gc", false);)

The following previously-failing packages appear to be fixed by the change:

• igv-2.9.4
• firebird25-client-2.5.9_1
• dub-1.14.0
• ghidra-9.1
• apache-openoffice-4.1.11
• apache-openoffice-devel-4.2.1633255994,4
• pioneer-20210723_1
• signald-0.15.0
• onedrive-2.4.12
• keepass-2.46
• reptyr-0.8.0
• gtk-sharp-beans-2.14.1_1
• gtkd-3.9.0

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260159

devel/dub, x11-toolkits/gtkd, and net/onedrive are due to ldc (https://github.com/ldc-developers/ldc/issues/3861): ld: error: undefined hidden symbol: __start_minfo.
(Quick workaround is to remove --gc-sections from ldc source)

All other ports appear unrelated to the linker change, e.g.

reptyr-0.8.0.log
212:platform/freebsd/arch/x86_common.h:45:6: error: variable 'ret' set but not used [-Werror,-Wunused-but-set-variable]
215:platform/freebsd/arch/x86_common.h:54:6: error: variable 'ret' set but not used [-Werror,-Wunused-but-set-variable]

apache-openoffice-4.1.11.log
65592:/usr/local/include/vigra/memory.hxx:43:12: fatal error: 'tr1/memory' file not found
87292:/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.11/main/xmerge/source/bridge/java/XMergeBridge.java:95: error: unknown tag: implements
... (other Java compile errors)


apache-openoffice-devel-4.2.1633255994,4.log
52857:/usr/local/include/vigra/memory.hxx:43:12: fatal error: 'tr1/memory' file not found
52929:/usr/local/include/vigra/memory.hxx:43:12: fatal error: 'tr1/memory' file not found

[jrtc27]

Setting the option to OFF currently breaks lld/test/ELF/gc-sections-startstop-hint.s

[MaskRay]

• rebase (unsupport one extra test)
• update description (FreeBSD exp-run result is mostly fine with default -z start-stop-gc)

Honestly the diff has very low value now.

lld/CMakeLists.txt

option(LLD_BUILD_TOOLS
   "Build the lld tools. If OFF, just generate build targets." ON)
 
 option(LLD_DEFAULT_LD_LLD_IS_MINGW
     "Use MinGW as the default backend for ld.lld. If OFF, ELF will be used." OFF)
 if (LLD_DEFAULT_LD_LLD_IS_MINGW)
   add_definitions("-DLLD_DEFAULT_LD_LLD_IS_MINGW=1")
 endif()
 
+option(LLD_DEFAULT_NOSTART_STOP_GC
+  "Default ld.lld to -z nostart-stop-gc. If ON, C identifier name sections are
+  forced retained by __start_/__stop_ references. This may increase output size
+  for many instrumentations, but is compatible with GNU ld newer than 2015-10"
+  OFF)
+if (LLD_DEFAULT_NOSTART_STOP_GC)
+  add_definitions("-DLLD_DEFAULT_NOSTART_STOP_GC=1")
+endif()
+
 if (MSVC)
   add_definitions(-wd4530) # Suppress 'warning C4530: C++ exception handler used, but unwind semantics are not enabled.'
   add_definitions(-wd4062) # Suppress 'warning C4062: enumerator X in switch of enum Y is not handled' from system header.
 endif()
 
 include_directories(BEFORE
   ${CMAKE_CURRENT_BINARY_DIR}/include
   ${CMAKE_CURRENT_SOURCE_DIR}/include

lld/ELF/Driver.cpp

static void readConfigs(opt::InputArgList &args) {
   config->zOrigin = hasZOption(args, "origin");
   config->zPacPlt = hasZOption(args, "pac-plt");
   config->zRelro = getZFlag(args, "relro", "norelro", true);
   config->zRetpolineplt = hasZOption(args, "retpolineplt");
   config->zRodynamic = hasZOption(args, "rodynamic");
   config->zSeparate = getZSeparate(args);
   config->zShstk = hasZOption(args, "shstk");
   config->zStackSize = args::getZOptionValue(args, OPT_z, "stack-size", 0);
+#ifdef LLD_DEFAULT_NOSTART_STOP_GC
+  // -z start-stop-gc default matches GNU ld<2015-10 and ld64 section$start
+  // symbols and can decrease file size for many instrumentations.  However,
+  // some users need time to accommodate the -z nostart-stop-gc default, so this
+  // is added as a temporary workaround.
+  config->zStartStopGC =
+      getZFlag(args, "start-stop-gc", "nostart-stop-gc", false);
+#else
   config->zStartStopGC =
       getZFlag(args, "start-stop-gc", "nostart-stop-gc", true);
+#endif
   config->zStartStopVisibility = getZStartStopVisibility(args);
   config->zText = getZFlag(args, "text", "notext", true);
   config->zWxneeded = hasZOption(args, "wxneeded");
   setUnresolvedSymbolPolicy(args);
   config->power10Stubs = args.getLastArgValue(OPT_power10_stubs_eq) != "no";
 
   if (opt::Arg *arg = args.getLastArg(OPT_eb, OPT_el)) {
     if (arg->getOption().matches(OPT_eb))

lld/test/CMakeLists.txt

 if (CMAKE_CFG_INTDIR STREQUAL ".")
   set(LLVM_BUILD_MODE ".")
 else ()
   set(LLVM_BUILD_MODE "%(build_mode)s")
 endif ()
 
 string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_LIBS_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
 string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_TOOLS_DIR "${LLVM_RUNTIME_OUTPUT_INTDIR}")
 
 llvm_canonicalize_cmake_booleans(
   LLVM_ENABLE_ZLIB
   LLVM_ENABLE_LIBXML2
   LLD_DEFAULT_LD_LLD_IS_MINGW
+  LLD_DEFAULT_NOSTART_STOP_GC
   LLVM_HAVE_LIBXAR
   )
 
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
   ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
   MAIN_CONFIG
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py

lld/test/ELF/gc-sections-metadata-startstop.s

 # REQUIRES: x86
+# UNSUPPORTED: default-nostart-stop-gc
 # LINK_ORDER cnamed sections are not kept alive by the __start_* reference.
 
 # RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
 # RUN: ld.lld --gc-sections -z start-stop-gc -z nostart-stop-gc %t.o -o %t
 # RUN: llvm-objdump --section-headers -t %t | FileCheck  %s
 
 ## With -z start-stop-gc (default), non-SHF_LINK_ORDER C identifier name
 ## sections are not retained by __start_/__stop_ references.

lld/test/ELF/gc-sections-startstop-hint.s

 # REQUIRES: x86
+# UNSUPPORTED: default-nostart-stop-gc
 ## Some projects may not work with GNU ld<2015-10 (ld.lld 13.0.0) --gc-sections behavior.
 ## Give a hint.
 
 # RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
 # RUN: ld.lld %t.o -o /dev/null
 # RUN: ld.lld %t.o --gc-sections -z nostart-stop-gc -o /dev/null
 # RUN: not ld.lld %t.o --gc-sections -o /dev/null 2>&1 | FileCheck %s
 

lld/test/ELF/gc-sections-startstop.s

 ## Check that group members are retained or discarded as a unit.
 
 # REQUIRES: x86
+# UNSUPPORTED: default-nostart-stop-gc
 
 # RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
 # RUN: ld.lld %t.o --gc-sections -o %t
 # RUN: llvm-readelf -s %t | FileCheck %s
 
 # RUN: echo ".global __start___data; __start___data:" > %t2.s
 # RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %t2.s -o %t2.o
 # RUN: ld.lld -shared %t2.o --soname=t2 -o %t2.so

lld/test/lit.cfg.py

tar_version = subprocess.Popen(
         env=env)
     sout, _ = tar_version.communicate()
     if 'GNU tar' in sout.decode():
         config.available_features.add('gnutar')
 
 # ELF tests expect the default target for ld.lld to be ELF.
 if config.ld_lld_default_mingw:
     config.excludes.append('ELF')
+
+if config.ld_lld_default_nostart_stop_gc:
+    config.available_features.add('default-nostart-stop-gc')

lld/test/lit.site.cfg.py.in

 config.lld_tools_dir = "@LLD_TOOLS_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@Python3_EXECUTABLE@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.have_libxar = @LLVM_HAVE_LIBXAR@
 config.have_libxml2 = @LLVM_ENABLE_LIBXML2@
 config.sizeof_void_p = @CMAKE_SIZEOF_VOID_P@
 config.ld_lld_default_mingw = @LLD_DEFAULT_LD_LLD_IS_MINGW@
+config.ld_lld_default_nostart_stop_gc = @LLD_DEFAULT_NOSTART_STOP_GC@
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
 try:
     config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
     config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
     config.lld_libs_dir = config.lld_libs_dir % lit_config.params
     config.lld_tools_dir = config.lld_tools_dir % lit_config.params