This happens to fix the miscompilation that occurs when bpf-linker is
moved to LLVM's new pass manager. A later commit will avoid the
miscompilation more convincingly.
Trampoline cargo-in-cargo stdio through cargo:warning to ensure the user
sees all the output.
Use bpf-linker from git in CI so we can see what's going on there.
This gives a better view of the CI pipeline in Github.
Gives us control over what runs and when.
And finally, lets us check only a single status in mergify.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Remove the manual dependency tracking machinery in
integration-test/build.rs in favor of a build-dependency on
integration-ebpf. This required adding an empty lib.rs to create the
library target.
This allows integration-test/build.rs to be ignorant of bpf-linker.
Remove that in favor of the logic now in integration-ebpf.
Extract the symlink-to-bpf-linker logic from integration-test to xtask
and use it in a new build script in integration-ebpf, causing ebpf
probes to be rebuilt when bpf-linker changes. Previously bpf-linker
changes would rebuild integration-test, but not integration-ebpf,
resulting in stale tests.
Note that this still doesn't address the possibility that a new
bpf-linker is added to the PATH ahead of the cached one. Solving this in
the general case would require rebuild-if-changed-env=PATH *and*
rebuild-if-changed={every-directory-in-PATH} which would likely mean far
too much cache invalidation.
This works now that build.rs does the right thing.
Update the `miri test` command in the lint job so it has the proper
exclusions; it is now in line with the invocations in the build-test job.
The ebpf probes require a nightly compiler. Before this change, if you
ran `cargo xtask integration-test` with a stable compiler toolchain as
default, or you ran `cargo +stable xtask integration-test`, you would
have seen an error like the one below. This is now fixed by running the
cargo build command in the integration-ebpf directory and making sure
to clear the RUSTUP_TOOLCHAIN env var.
```
--- stderr
/home/ajwerner/src/github.com/aya-rs/aya/test/integration-test/bpf/ring_buf_sched_tracepoint.bpf.c:18:21: warning: declaration of 'struct switch_args' will not be visible outside of this function [-Wvisibility]
int bpf_prog(struct switch_args* ctx)
^
1 warning generated.
error: the `-Z` flag is only accepted on the nightly channel of Cargo, but this is the `stable` channel
See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
thread 'main' panicked at '"cargo" "build" "-p" "integration-ebpf" "-Z" "build-std=core" "--release" "--message-format=json" "--target" "bpfel-unknown-none" "--target-dir" "/home/ajwerner/src/github.com/aya-rs/aya/target/debug/build/integration-test-9bbcb3db5e9f8f57/out/integration-ebpf" exited
with status code 101:
', test/integration-test/build.rs:219:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: error while building userspace application
Caused by:
Child { stdin: None, stdout: None, stderr: None, .. } exited with status code 101:
```
Libbpf is used by xtasks, in the command, ensure that the submodules
are initialized. This eases the user-experience so that users don't
need to think about the submodule, while retaining all the benefits
of using a submodule vs forcing the user to manually check out libbpf
and stick it in some pre-defined place.
We use the symbol pointing to libbpf in xtask in the build script
to avoid repeating this constant.
Also, we install git in the vm so that we can init the submodule
when we build in the vm.
Emit "cargo:rerun-if-changed={}" for each transitive dependency on
integration-ebpf. In a normal world we'd just add integration-ebpf to
our build-dependencies, but cargo ignores this because integration-ebpf
has no library targets.
The matches crate has been archived now that `matches!` is in std.
However `assert_matches!` is still unstable in std, and the
assert_matches crate provides a more expressive form:
```
assert_matches!(foo, Ok(bar) => {
assert_eq!(bar, baz);
});
```
This feature is equivalent to async_tokio || async_std; removing it
avoids warnings emitted during `cargo hack check --feature-powerset`
where async is selected without either of the other features.
Use cargo hack to ensure clippy runs on the powerset of features.
Dave Tucker
dependabot[bot]
vadorovsky
Tamir Duberstein
ajwerner
Alessandro Decina