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

Comment From: gabyhelp

Related Issues

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

Comment From: 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?

Comment From: 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

Comment From: 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.

Comment From: gopherbot

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