/ go Public
cmd/compile: interaction between sync/atomic, -race and go:norace #43007
Issues related to the Go compiler and/or runtime.
Feedback is required from experts, contributors, and/or the community before a change can be made.
The issue is discovered on gVisor with coverage and race instrumentation. gVisor has some sensitive functions marked as
go:norace(calling into race detector will crash I assume).
With atomic coverage instrumentation (the mode bazel uses now) these functions get coverage instrumentation with
sync/atomic.AddUint32calls, which is fine per se because these are just increments of a global so can run in almost any context.
But if we add race instrumentation to the mix, atomic calls become super complex (call into race runtime) and crash. This is not an issue for all other operations as the function is marked as
Question: should compiler leave atomic operations uninstrumented in such case?
It currently transforms atomic operations to machine instructions directly in -race is not enabled, so if it just continued doing so for
go:noracefunctions it would solve the issue. However, I don't know if it does this transformation for all arches. Otherwise it will require calling
Another option may be
go version devel +edf60be151 Fri Dec 4 18:03:43 2020 +0000 linux/amd64
The text was updated successfully, but these errors were encountered: