Age | Commit message (Collapse) | Author |
|
This change two does things:
1) Name the container based on the canonical directory path.
2) Allow the container to exit after bazel itself has exited.
The first is necessary to support multiple working directories,
while the second one allows these instances to clean up properly.
PiperOrigin-RevId: 310460748
|
|
Updates #2569
Updates #2298
PiperOrigin-RevId: 310423629
|
|
PiperOrigin-RevId: 309801320
|
|
PiperOrigin-RevId: 309265978
|
|
PiperOrigin-RevId: 309176385
|
|
PiperOrigin-RevId: 308901116
|
|
This change moves all Docker images to a standard location, and abstracts the
build process so that they can be maintained in an automated fashion. This also
allows the images to be architecture-independent.
All images will now be referred to by the test framework via the canonical
`gvisor.dev/images/<name>`, where `<name>` is a function of the path within the
source tree.
In a subsequent change, continuous integration will be added so that the images
will always be correct and available locally.
In the end, using `bazel` for Docker containers is simply not possible. Given
that we already have the need to use `make` with the base container (for
Docker), we extend this approach to get more flexibility.
This change also adds a self-documenting and powerful Makefile that is intended
to replace the collection of scripts in scripts. Canonical (self-documenting)
targets can be added here for targets that understand which images need to be
loaded and/or built.
PiperOrigin-RevId: 308322438
|
|
This change adds a layer of abstraction around the internal Docker APIs,
and eliminates all direct dependencies on Dockerfiles in the infrastructure.
A subsequent change will automated the generation of local images (with
efficient caching). Note that this change drops the use of bazel container
rules, as that experiment does not seem to be viable.
PiperOrigin-RevId: 308095430
|
|
Even though the default build option is to use 1.14, we want to be
want to keep the ability to target different Go versions for testing
and in case the new release has bugs.
PiperOrigin-RevId: 308078876
|
|
PiperOrigin-RevId: 307941984
|
|
See tools/nogo/README.md.
The checkescape tool is able to perform recursive escape analysis, using the
actual generated binary to confirm the results produced by the compiler itself.
As an initial use case, this replaces the manual escape analysis tests used for
go_marshal, and validates that the CopyIn and CopyOut paths will not require
any allocation or stack splits.
Updates #2243
PiperOrigin-RevId: 307532986
|
|
This change renames the tools/images directory to tools/vm for clarity, and
adds a functional vm_test. Sharding is also added to the same test, and some
documentation added around key flags & variables to describe how they work.
Subsequent changes will add vm_tests for other cases, such as the runtime tests.
PiperOrigin-RevId: 307492245
|
|
PiperOrigin-RevId: 306300032
|
|
PiperOrigin-RevId: 306289643
|
|
PiperOrigin-RevId: 305944892
|
|
PiperOrigin-RevId: 305940483
|
|
PiperOrigin-RevId: 305927989
|
|
PiperOrigin-RevId: 305922105
|
|
PiperOrigin-RevId: 305807868
|
|
It seems no longer necessary.
PiperOrigin-RevId: 305758572
|
|
Minimize the use of unsafe.
Signed-off-by: Bin Lu <bin.lu@arm.com>
|
|
PiperOrigin-RevId: 305592245
|
|
Updates #2243
|
|
This fixes a bug in the proc net directory.
Updates #2243
|
|
Updates #2243
|
|
This required minor restructuring of how system call tables were saved
and restored, but it makes way more sense this way.
Updates #2243
|
|
Previously, go-marshal only allowed literals for array
lengths. However, it's very common for ABI structs to have a fix-sized
array whose length is defined by a constant; for example PATH_MAX.
Having to convert all such arrays to have literal lengths is too
awkward.
PiperOrigin-RevId: 304289345
|
|
Previously, the import statement collision detection mechanism aborted
go-marshal whenever it detected two imports in any package that has
the same local name. Consider this trivial package, defined by the the
following two source files:
file1.go:
package example
import (
path/a/to/foo
)
...
file2.go:
package example
import (
another/package/with/final/component/foo
)
...
Go-marshal previously couldn't handle generating code for the the
above package, even if none of the types marked for marshalling used
either of the imported foo packages. This turns out to be too
restrictive as we run into this a lot in practice. Examples include
"encoding/binary" vs "gvisor/pkg/binary/binary", and "sync" vs
"gvisor/pkg/sync/sync".
This change allows go-marshal to proceed with marshalling, and only
abort if the code generated by go-marshal references any such
ambiguous import names.
PiperOrigin-RevId: 304131190
|
|
PiperOrigin-RevId: 304119255
|
|
PiperOrigin-RevId: 303805784
|
|
PiperOrigin-RevId: 303773475
|
|
|
|
This enables all relevant santizers (though most analyzers will not find
much, it will prevent instances from creeping in), and codifies existing
exceptions in tools/nogo.js to be fixed.
|
|
There is a canonical naming convention for Examples, which are checked
by analyzers. This must be fixed since adding exceptions for generated
code will be more challenging.
|
|
The posix_server works fine when run in locally or in docker but fails in the
kokoro GCP build environment. Linking libpthread statically fixes it.
PiperOrigin-RevId: 302139082
|
|
Fixes random stuff that is broken on bazel/kokoro.
- random output coming back as "bytes" object instead of str
- missed syntax error in bazel
- a flag is missing in the version of gcloud on kokoro
PiperOrigin-RevId: 301915289
|
|
PiperOrigin-RevId: 301382690
|
|
|
|
This is frequently causing the core build scripts to fail. The core ubuntu
distribution will perform an auto-update at first start, which may cause the
lock file to be held. All apt-get commands may be done in a loop in order to
retry to avoid this issue. We may want to consider retrying other pieces, but
for now this should avoid the most frequent cause of build flakes.
PiperOrigin-RevId: 297704789
|
|
PiperOrigin-RevId: 297693838
|
|
PiperOrigin-RevId: 297628615
|
|
PiperOrigin-RevId: 296519566
|
|
Sometimes, when we start a new instance, the file
lock on "apt" is locked. Add a loop to the master
installer.
In addition, the "apt-get install" fails to register
runsc in docker, so run the appropriate scripts to
get that to happen.
Also, add some helpful log messages.
PiperOrigin-RevId: 296497357
|
|
PiperOrigin-RevId: 296322954
|
|
Users of the API only care about whether the copy in/out succeeds in
their entirety, which is already signalled by the returned error.
PiperOrigin-RevId: 296297843
|
|
This simplifies the script slightly.
PiperOrigin-RevId: 296272077
|
|
PiperOrigin-RevId: 296104390
|
|
This can happen due to conditional compilation, where a subset of the
source files contain no marshallable types. go-marshal is still
required to write an output file in these cases, since bazel defines
the output package before calling go-marshal.
PiperOrigin-RevId: 296074321
|
|
Since we tag entire packages as marshallable, due to conditional
compiling for different architectures we can end up with sets of
source files that don't contain any marshallable types. It's safe to
silently ignore this scenario.
PiperOrigin-RevId: 295831871
|
|
This lets go-marshal replace various calls to binary.Size() throughout
the sentry without requiring concrete objects.
PiperOrigin-RevId: 295299965
|