cmd/link: TestDWARF failing on freebsd/arm since August 2020

[aclements]

The freebsd-arm-paulzhol builder has been failing since August with

--- FAIL: TestDWARF (8.89s)
    dwarf_test.go:41: cmd/link is stale - run go install cmd/link
FAIL
FAIL	cmd/link	125.383s

Unfortunately, the builder has been mostly out-to-lunch for a long time (cc @paulzhol ). The last successful run was 4489f4b on June 5th and the first failing run was 8acbe4c on August 22nd.

@golang/osp-team , what should we do about this builder and/or the freebsd/arm port?

cc @cherrymui @jeremyfaller @thanm since it's a linker test. But the builder is effectively inaccessible, so it would be very hard to test a fix.

[paulzhol]

@aclements I've tried to debug it in #41101 but without much success. I will gladly provide access / bring it back online. I was planning to upgrade it to FreeBSD 12.2.

[jeremyfaller]

I think I've seen that failure when there was non-reproducible object files. I believe that there was a bug I introduced sometime during that pass/fail window that Cherry fixed, and that test should universally pass.

[cherrymui]

Personally I don't really like that stale check. I understand that it was there to catch the situation where someone is developing the linker locally, runs go test without go installing the linker first, which will get a wrong result. But I don't think it belongs to that particular test.

• it isn't useful for a builder or CI system (where the toolchain is always freshly built)
• if we want to do that, it'd probably better be an init function or TestMain.

It is true that it is weird that the linker is reported stale there (and not earlier by cmd/dist, if it is really stale). I could try to debug. But I also want to bring up the idea that we just remove that staleness check.

[paulzhol]

As I understand it, the test is already disabled for darwin-amd64 builders by https://golang.org/cl/223925.

[bcmills]

@cherrymui

it isn't useful for a builder or CI system (where the toolchain is always freshly built)

For the moment, at least, the staleness check is useful in CI because it helps to detect cases where the build of the toolchain is somehow incomplete, corrupted, or out of sync (such as #33598 and #35740, which have yet to be diagnosed and fixed).

It's fine to remove the check if it isn't actually verifying a property relevant to the test, but if the staleness of cmd/link actually is relevant to the test then the check should stay — if we remove it, that just papers over some underlying problem that remains for the builder.

[aclements]

Sorry, I'd missed that this was already reported in #41101 (I searched around but somehow didn't find that). Let's close this as a dup and move the conversation over there.