cmd/link: TestFlagD failing on OpenBSD [consistent failure]

[prattmic]

The openbsd-amd64 and openbsd-ppc64 builders are broken because the new TestFlagD test, added in https://go.dev/cl/698355, is consistently failing.

Example failure: https://ci.chromium.org/ui/p/golang/builders/ci/gotip-openbsd-ppc64/b8703999156992273425/overview

=== RUN   TestFlagD
=== PAUSE TestFlagD
=== CONT  TestFlagD
    elf_test.go:653: data section starts at 0x0, expected 0x10000000
--- FAIL: TestFlagD (5.06s)

My immediate guess is the test's search for the data section isn't quite right for OpenBSD.

cc @golang/compiler @golang/openbsd @kevaundray

[gabyhelp]

Related Issues

• doc/progs: flaky on OpenBSD #10497 (closed)
• Compilation fails in OpenBSD 7.1 #57148 (closed)
• misc/cgo/test: internal linking now fails on openbsd/arm64 #31940 (closed)
• x/tools/gopls/internal/test/integration: tests failing on openbsd/amd64 due to stalling and timing out #72145
• cmd/go: TestScript fails or flakes on OpenBSD #28677 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cherrymui]

Apparently, on OpenBSD, the code searching for data section found the .tbss section. readelf -S output is like

  [24] .tbss             NOBITS           0000000000000000  00000000
       0000000000000008  0000000000000000 WAT       0     0     8

This section does not exist on Linux.

I wonder why we look for section with sec.Type == elf.SHT_NOBITS. A data section should always be SHT_PROGBITS, right?

Also, we could assume sections are in address order and stop at the first matching one, instead of looking for the one with smallest address.

Or (by both the SHT_NOBITS and searching for a smaller address) you want to ensure that the BSS segment is mapped at higher address?

[kevaundray]

Apparently, on OpenBSD, the code searching for data section found the .tbss section. readelf -S output is like

  [24] .tbss             NOBITS           0000000000000000  00000000
       0000000000000008  0000000000000000 WAT       0     0     8

This section does not exist on Linux.

I wonder why we look for section with sec.Type == elf.SHT_NOBITS. A data section should always be SHT_PROGBITS, right?

Also, we could assume sections are in address order and stop at the first matching one, instead of looking for the one with smallest address.

Or (by both the SHT_NOBITS and searching for a smaller address) you want to ensure that the BSS segment is mapped at higher address?

I classified bss as data too, so the or statement catches both sec.Type == elf.SHT_PROGBITS || sec.Type == elf.SHT_NOBITS

Seems we could differentiate tbss with something like isTLS := sec.Flags&elf.SHF_TLS != 0, though its unclear to me why that section was not shifted up too

[cherrymui]

The TLS section's address is an offset into the per-thread TLS image. It is not an absolute address, as it is different on each thread, by definition.

The simplex fix is to filter out the TLS sections. If there is still failure on some other platform, we can adjust the condition. Sent CL 703375.

[gopherbot]

Change https://go.dev/cl/703375 mentions this issue: cmd/link: don't count tbss section in TestFlagD