Conversation
|
I resolved two bugs relating to intrinsics, fixing one of the three test failures we had earlier. Another I understand the problem - it relates to the linker's checking of what packages are allowed to reach for specific linknames - but I need to think a bit about what the correct solution is here. |
It can be rather slow on multi-megabyte binaries, and its output can also be pretty massive at times. Let the user run it separately on the files we store to the bincmp_output directory.
This starts causing a failure on Go 1.26, which we only capture
in another test via `go test` by accident, so make sure we cover it.
Without a fix and on go1.26, I now see:
> exec garble build -o=main$exe ./stdimporter
[stderr]
# test/main/stdimporter
link: x9BrC6t: invalid reference to runtime.pprof_goroutineLeakProfileWithLabels
We still test GOARCH=arm64 as part of darwin/arm64 below.
Make runtimeAndLinknamed a set, like the other tables, for easy lookups which will come in handy for Go 1.26 support. Run `go list` across multiple platforms to ensure we cover all bases. This again will help for Go 1.26 support, which introduces more packages specific to MacOS and Windows.
|
@luantak all tests are passing for me now on go1.26.1, PTAL. I did multiple commits because I needed multiple tweaks and fixes which could be done before the big flip to 1.26, and that should also make the code review a bit easier. |
mvdan
changed the title
Beyond the usual updating of version strings, re-running `go generate`, and updating the patches for the linker, we needed extra changes. First, the linker started being stricter about which packages are allowed to linkname runtime names by import path. Stop obfuscating import paths in runtimeAndLinknamed. Second, the compiler's intrinsics code adds an "add" function much like the existing "addF", so tweak the regular expression. Third, note that there is a new runtimeAndDeps windows-only package, which we find thanks to the recent improvement to cover many platforms. Fourth, the code around magic numbers in the runtime has changed, so rewrite the code which patches it via go/ast. Fixes burrowers#990.
|
Hm. Windows is badly broken. This will be hard for me to debug because I don't have a Windows machine right now. Any help appreciated. |
|
Ah, this could very well be golang/go#77975, which has extremely similar fatal error messages. The fix for that is going to be released with go1.26.2 very soon. On the basis that I suspect the majority of our users are on Linux/Mac, and that we can't do much for now until 1.26.2 is released to further investigate Windows, I might go ahead and merge with Windows failing. I'm re-running Linux and Mac to see if they're green. |
This was causing a number of failures on GOOS=darwin in CI. Thanks to LOVECHEN on GitHub for suggesting this.
3 participants
(see commit messages - please do not squash)