Upstream Go CL https://go.dev/cl/652276 removes an unused field from
runtime.gobuf. This CL prepares for this change.
This CL also simplifies the build constraints in the hosttid files:
- Remove legacy '// +build' constraint syntax
- Remove explicit GOARCH matching. The GOARCH is in the filename
PiperOrigin-RevId: 733382770
For all trivial and zero frame-sized functions, we now require an explicit
NOFRAME annotation as the heuristic has changed. See go.dev/cl/466316.
Most of these functions do not *require* NOFRAME, but this change encodes
the existing behavior in order to avoid accidental bugs or regressions.
PiperOrigin-RevId: 513946210
This allows fact information to be validated in the underlying source files,
but requires us to explicitly maintain this in appropriate version-tagged, and
architecture-tagged files. This is more explicit and safer.
This mechanism uses a special regular expression for matching a +checkconst
stanza to validate constant values, sizes and offsets. This applies to both Go
source files and assembly files.
PiperOrigin-RevId: 511867507
This removes the need for ongoing tags.
This change requires some minor updates to remove dependency cycles, since
the goid package is a base library used by many internals (log, sync, etc.).
PiperOrigin-RevId: 504066914
Upstream Go tip has updated its version to 1.19, so we need to bump these build
tags to allow tip testing.
This CL bumps the minimum version in pkg/sync/runtime_amd64.s from 1.8 to 1.14.
The offset was different prior to Go 1.14.
Ideally we'll get checklinkname (or equivalent) to check these remaining unsafe
uses (like internal struct field offsets) soon.
For golang/go#51445.
PiperOrigin-RevId: 433304124
Go's dev.typeparams branch already claims to be Go 1.18, so our !go1.18 build
tags breaking testing gVisor with that branch.
Normally I would not want to bump the build tags this early, but I plan to
extend checklinkname to check the assumptions in these files and remove the
build tags ASAP. So we just go ahead and bump the tags until then to unblock
testing.
PiperOrigin-RevId: 389037239
We would like to track locks ordering to detect ordering violations. Detecting
violations is much simpler if mutexes must be unlocked by the same goroutine
that locked them.
Thus, as a first step to tracking lock ordering, add this lock/unlock
requirement to gVisor's sync.Mutex. This is more strict than the Go standard
library's sync.Mutex, but initial testing indicates only a single lock that is
used across goroutines. The new sync.CrossGoroutineMutex relaxes the
requirement (but will not provide lock order checking).
Due to the additional overhead, enforcement is only enabled with the
"checklocks" build tag. Build with this tag using:
bazel build --define=gotags=checklocks ...
From my spot-checking, this has no changed inlining properties when disabled.
Updates #4804
PiperOrigin-RevId: 343370200
gVisor bot
Adin ScannellandgVisor bot
Michael PrattandgVisor bot
Jamie LiuandgVisor bot
Bin Lu
Ian GudgerandgVisor bot