For some commercial software, some features are considered "supportability features" that help with triage and resolution of user problems. For example, it might be that something helps the support organization, or helps a customer resolve via "self service", or helps the engineering team resolve faster when a problem is escalated to them.

Suggestion

In a similar vein, it might be nice to fairly prominently report that -checklinkname=0 was used when the runtime has detected a problem.

Possible benefits

A particular problem might not be related to the use of -checklinkname=0, but it might be.

If someone has reported a problem on the Go issue tracker and it is clear they are using -checklinkname=0, a natural triage step might be to ask them to first see if they can reproduce the problem without use of -checklinkname=0.

Separately, if someone is running some private code internally and sees some fatal error, if they are reminded that -checklinkname=0 is in use, it might nudge them a tiny bit towards doing that triage step themselves, which might translate to no bug being reported on the Go issue tracker in some cases.

Making the use of -checklinkname=0 more prominent might also be the tiniest of nudges for different packages to start moving off of its use (though that would likely take a long time).

Draft CL

I sent https://go.dev/cl/719300 as a quick first cut of the concept.

In short, it updates the linker to write to a boolean value when -checklinkname=0 is used, and the boolean is then read by the runtime in the throw and fatal functions to decide whether to include additional context when printing the fatal error.

Opening this issue here to see if there is some rough consensus for trying something like what is outlined above, vs. maybe not.

Possible extensions

I think it could be natural and beneficial to possibly extend this general concept in some fashion to the use of cgo and unsafe (perhaps outside of a narrow allowlist like unsafe.Sizeof), and/or uses of go:linkname outside of the stdlib that do not rely on -checklinkname=0.

These could follow a similar approach, or perhaps have a different manifestation than what is shown in the draft CL here.

For these, it could be more debatable whether it is better for the main Go toolchain to report their use (similar in spirit to the draft CL here), vs. better for something like an auxiliary program in x/tools or x/exp or similar that reports usage via static analysis, vs. trying to encourage more use of capslock or similar.

Some discussion of possible extensions could be worthwhile here, though I think it is probably good to mostly focus this particular issue on -checklinkname=0, which is maybe an easier place to start.