This updates the Google Cloud APIs and their Go libraries to their latest
versions, which adds some of the missing fields of the container cluster
service v1 proto that didn't exist in the version defined in `WORKSPACE`.
This also severs the proto import dependency of `test_range_config.proto` on
the container cluster API proto, both because it shouldn't be GKE-specific
but also because the Go genproto version of the container cluster API is
different (from the Go linker's perspective) from the container cluster
proto that is imported from `test_range_config.proto`. Instead, it is
encoded as an "any" proto for both nodepools and clusters.
Go repositories are re-arranged such that the genproto version imported is
taken from the `WORKSPACE` file rather than the one embedded in other Go
repositories earlier in the file.
The version of this API in Go's genproto library is still missing some of
the TPU node placement fields, so that part is filled in via reflection
when available. That is hacky but that codepath only applies to TPU clusters
so not applicable for most benchmarks.
PiperOrigin-RevId: 688682505
This adds cgo-only arguments passed to `go_library` rules when the
`bazel_cgo` argument is specified and `True`.
Credits go to @avagin for this change.
Updates #9266
Updates #9551
PiperOrigin-RevId: 677085717
Our Bazel build infrastructure explicitly recognizes some suffixes that can
appear at the end of filenames (tools/bazeldefs/tags.bzl). It uses these tags
to group files passed to go_stateify (tools/defs.bzl:go_library() =>
calculate_sets()).
Each invocation of go_stateify infers build tags from its input files. Before
this CL, all Go files in pkg/tcpip/link/fdbased (except for fdbased_unsafe.go)
are grouped together to generate fdbased_state_autogen.go, so go_stateify
infers builds tags "!linux !amd64,!arm64" (from mmap_stub.go) and "linux ..."
(from most other files); these contradictory build tags mean that
fdbased_state_autogen.go is never actually compiled, preventing its types from
being registered. After this CL, mmap_nonlinux.go independently generates
fdbased_nonlinux_state_autogen.go.
Fixing this causes fdbased_state_autogen.go to be included for the first time,
exposing a second problem:
```
pkg/tcpip/link/fdbased/endpoint_test.go:80:6: context already declared through import of package context ("context")
.../pkg/tcpip/link/fdbased/fdbased_state_autogen.go:12:2: other declaration of context
```
(Apparently Go imports are a pessimal hybrid of "shared between files in a
package" and "not shared between files in a package".) To fix this, rename the
test type to testContext.
PiperOrigin-RevId: 663522480
Instead of lying to clang about the targeted system, we can install the
necessary package only on x86_64 machines. Our tooling supports multiarch
packages (see tools/images.mk).
PiperOrigin-RevId: 591385576
system_malloc is causing test flakes.
The issue with tcmalloc is it isn't fork-safe and any allocations in forked
sub-processes can stuck.
PiperOrigin-RevId: 581372831
We don't want these checks in the production binary at all. Even though the
hardware branch predictor will do away with any runtime costs of the if
condition, the code under the "if checkInvariants {...}" could force escapes
to the heap. It could also increase function complexity, making it no longer
inlinable. And these invariant checks lie on hot code paths.
PiperOrigin-RevId: 513398208
The systrap platform like the ptrace platform uses stub processes to manage
the user address space. The difference is how they intercept system calls and
other events like memory faults, exceptions, etc.
In case of systrap, all events that have to be handled by the Sentry trigger
signals that are handled by a custom signal handler installed on stub
processes. The signal handler switches control to the Sentry.
Here are a few other optimizations:
* On x86, system calls can be replaced with a function call to remove overhead
of signals.
* For fast interactions of sentry and stub processes, futex wait/wake can
be a bottle neck, so we use a polling mode.
The platform is launched for the purpose of testing and gathering initial
feedback. It is not yet ready for use in production.
PiperOrigin-RevId: 511650064
After update to Go 1.20 in 5572ab2f7d ("Bump go version to 1.20"), the
benchmark jobs have been failing on BuildKite. This seems to be happening
because benchmark test binaries are built in Docker containers but are run on
the host. On some hosts, the glibc isn't compatible with glibc in our docker
container. So dynamically linked binaries may fail. Linking them statically
resolves this glibc compatibility issue.
As a result, this change also adds support for static test binaries to
tools/bazeldefs/go.bzl.
PiperOrigin-RevId: 510455271
gVisor bot
Andrei Vagin
Lucas ManningandgVisor bot
Etienne PerotandgVisor bot
Jamie LiuandgVisor bot
Jing ChenandgVisor bot
Nayana BidariandgVisor bot
Kevin KrakauerandgVisor bot
Andrei Vagin
Adin ScannellandgVisor bot
Ayush RanjanandgVisor bot