cmd/go: ignore *.syso files in -msan mode #21884
Comments
|
Change https://golang.org/cl/63917 mentions this issue: |
There's no way for a *.syso file to be compiled to work both in normal mode and in msan mode. Assume they are compiled in normal mode and drop them in msan mode. Packages with syso files currently fail in -msan mode because the syso file calls out to a routine like memcmp which then falsely reports uninitialized memory. After this CL, they will fail in -msan with link errors, because the syso will not be used. But then it will at least be possible for package authors to write fallback code in the package that avoids the syso in -msan mode, so that the package with the syso can at least run in both modes. Without this CL, that's not possible. See #21884. Change-Id: I77340614c4711325032484e65fa9c3f8332741d5 Reviewed-on: https://go-review.googlesource.com/63917 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
Change https://golang.org/cl/65488 mentions this issue: |
There's no way for a *.syso file to be compiled to work both in normal mode and in msan mode. Assume they are compiled in normal mode and drop them in msan mode. Packages with syso files currently fail in -msan mode because the syso file calls out to a routine like memcmp which then falsely reports uninitialized memory. After this CL, they will fail in -msan with link errors, because the syso will not be used. But then it will at least be possible for package authors to write fallback code in the package that avoids the syso in -msan mode, so that the package with the syso can at least run in both modes. Without this CL, that's not possible. See #21884. Change-Id: I77340614c4711325032484e65fa9c3f8332741d5 Reviewed-on: https://go-review.googlesource.com/63917 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/65488 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
|
@rsc any reason not to cherry-pick on master (with docs)? |
|
There is instruction how to add .icon based on .syso and not working In any case of .syso looks not working |
ianlancetaylor
added
the
NeedsFix
|
This is OK to cherry pick to master. |
|
@FiloSottile @andybons @bradfitz, in #21884 (comment) Russ gave the go ahead to cherry pick from dev.boringcrypto. I'd do it but I don't have the forge-author Gerrit permission. |
|
I'm concerned that people might use build tags to make this work today, which would stop working if we unilaterally ignore .syso files in msan mode. |
|
How would using build tags work? |
|
Packages with syso files currently fail in -msan mode because the syso file calls out to a routine like memcmp which then falsely reports uninitialized memory.
It's not possible to prepare a syso file that works regardless of memory-sanitizer setting, at least not if the code makes any memory writes, which most code does. Instead you'd have to prepare both a standard syso and an msan-enabled syso, and the go command conventions provide no way to tell those apart.
I suggest we simply ignore syso files in -msan mode. That will result in missing link symbols, but then package authors can revise their packages to avoid the syso in -msan mode. That gives package authors at least one way to write a package that has a syso and still works with -msan. Today there are zero ways.
A more complex change would be to introduce a new class of objects like *.syso.msan or *_msan.syso, but let's not do that until there's a compelling reason. In the case where this came up, the "ignore syso files" is good enough.
The text was updated successfully, but these errors were encountered: