CL https://golang.org/cl/17144 mentions this issue.

Works on my machine.
Guess it's a builder problem.

% sh
$ eval `~/go/bin/go tool dist env -p`
$ go test -v -run 'TestNoteReading' cmd/go
=== RUN   TestNoteReading
--- PASS: TestNoteReading (0.69s)
        go_test.go:257: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -o /tmp/gotest292090317/hello.exe /tmp/gotest292090317/hello.go]
        go_test.go:257: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -linkmode=external -o /tmp/gotest292090317/hello.exe /tmp/gotest292090317/hello.go]
=== RUN   TestNoteReading2K
--- PASS: TestNoteReading2K (0.71s)
        go_test.go:257: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -o /tmp/gotest559435976/hello.exe /tmp/gotest559435976/hello.go]
        go_test.go:257: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -linkmode=external -o /tmp/gotest559435976/hello.exe /tmp/gotest559435976/hello.go]
PASS
ok      cmd/go  7.773s
$ ^D

When we had bug #13146 I used retrybuilds to redo several of the most recent builds. Each one failed with this build ID issue. The place where this error first starts is the oldest version where I retried the build, not the commit where it was first could happen.

The machine where this testing is done is running DragonFly-master, and was updated at the time the fix for bug #13146 was applied, which brought in gold as the default linker.

Running the same test as @kaey fails on the build machine. Setting LDVER=ld.bfd, which sets the default linker back to ld and re-running the test succeeds. So, each of those failed tests is running with gold as the default linker, and that's the cause for the failure rather than an individual commit.

The readelf output between the old linker and the gold linker on a super-basic hello.c program on DragonFly is almost exactly the same, except the gold linker also outputs this:

Displaying notes found at file offset 0x00000b04 with length 0x0000001c:
  Owner                 Data size Description
  GNU                  0x00000009 NT_GNU_GOLD_VERSION (gold version)
    Version: gold 1.11

I thought it might be similar to #12178 but the offset only puts it past the first 512 bytes, and I think anywhere in the first 16K is OK - unless the gold output is the issue. I am not familiar with this.

Running
go build -ldflags -buildid=TestNoteReading-Build-ID -o hellotest.exe hello.go
readelf -n hellotest.exe

Gives identical results with ld or gold :

Displaying notes found at file offset 0x00000fd8 with length 0x00000028:
  Owner                 Data size Description
  Go                   0x00000018 Unknown note type: (0x00000004)

Can you post a copy of the hellotest.exe you generated with gold somewhere?
Thanks.

On Tue, Nov 24, 2015 at 10:20 PM, Justin Sherrill notifications@github.com
wrote:

When we had bug #13146 #13146 I used
retrybuilds to redo several of the most recent builds. Each one failed with
this build ID issue. The place where this error first starts is the oldest
version where I retried the build, not the commit where it was first could
happen.

The machine where this testing is done is running DragonFly-master, and
was updated at the time the fix for bug #13146
#13146 was applied, which brought in
gold as the default linker
http://lists.dragonflybsd.org/pipermail/commits/2015-November/458732.html
.

Running the same test as @kaey https://github.com/kaey fails on the
build machine. Setting LDVER=ld.bfd, which sets the default linker back to
ld and re-running the test succeeds. So, each of those failed tests is
running with gold as the default linker, and that's the cause for the
failure rather than an individual commit.

The readelf output between the old linker and the gold linker on a
super-basic hello.c program on DragonFly is almost exactly the same, except
the gold linker also outputs this:

Displaying notes found at file offset 0x00000b04 with length 0x0000001c:
Owner Data size Description
GNU 0x00000009 NT_GNU_GOLD_VERSION (gold version)
Version: gold 1.11

I thought it might be similar to #12178
#12178 but the offset only puts it
past the first 512 bytes, and I think anywhere in the first 16K is OK -
unless the gold output is the issue. I am not familiar with this.

Running
go build -ldflags -buildid=TestNoteReading-Build-ID -o hellotest.exe
hello.go
readelf -n hellotest.exe

Gives identical results:

Displaying notes found at file offset 0x00000fd8 with length 0x00000028:
Owner Data size Description
Go 0x00000018 Unknown note type: (0x00000004)

—
Reply to this email directly or view it on GitHub
#13364 (comment).

http://shiningsilence.com/go-gold/

Minimal program in hello.go, compiled with 'go build -ldflags -buildid=TestNoteReading-Build-ID -o hellotest-[gold|ld].exe hello.go', and resulting binaries are done with gold and with old ld, appropriately named.

At the link http://shiningsilence.com/go-gold/ the files hellotest-gold.exe and hellotest-ld.exe are identical.

Looking at the error output when running the test:

# go test -v -run 'TestNoteReading' cmd/go
=== RUN   TestNoteReading
--- FAIL: TestNoteReading (1.51s)
        go_test.go:251: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -o /tmp/gotest104822668/hello.exe /tmp/gotest104822668/hello.go]
        go_test.go:251: running testgo [build -ldflags -buildid=TestNoteReading-Build-ID -linkmode=external -o /tmp/gotest104822668/hello.exe /tmp/gotest104822668/hello.go]
        note_test.go:46: buildID in hello binary = "", want "TestNoteReading-Build-ID" (linkmode=external)
FAIL
exit status 1
FAIL    cmd/go  15.190s

Is it perhaps the linkmode=external that's killing it? That was not in the identical test versions

@fupjack Did you see my note that on the link you provided, the two hellotest executables are identical? They are both from GNU ld. You didn't provide the one linked by gold.

@fupjack We want to the test to pass using external linking. The test builds the binary twice, once with default linking and once with external linking.

Fixed - different binaries in place at http://shiningsilence.com/go-gold/ - I made sure this time.

MD5 (hellotest-gold.exe) = 92b68ba2a3c271a664568ff6c5cf6ac4
MD5 (hellotest-ld.exe) = dd39183acefeb15e95a26015df3d96e6

Thanks. The problem is that the note reading code fails to handle multiple notes in a single PT_NOTE segment. I'll send a CL.

CL https://golang.org/cl/17331 mentions this issue.