Fix map creation failure when a BPF have a data section on older
kernel. (< 5.2)
If the BPF uses that section, relocation will fail accordingly and
report an error.
- Replace all `#[repr(usize)]` with `#[repr(u8)]`; this saves
3*(sizeof(word)-1) bytes per log message.
- Encode payload length as u16 rather than usize; this saves
sizeof(word)-1 bytes per log message. This is safe because the maximum
size of a log message is less than (1 << 16 - 1).
This changes `level` to a require field in every log message. It was
already always present, but was treated as optional when reading.
Previously `struct TagLenValue` was defined in both aya-log and
aya-log-common where the former implemented reading and the latter
writing; the reading logic doesn't need the struct, so remove it.
Remove mem::forget::<HashMap>() calls in tests which fail to compile when
HashMap is provided by hashbrown:
info: running `cargo check --all-targets --no-default-features` on aya-obj (11/23)
Checking aya-obj v0.1.0 (/home/tamird/src/aya/aya-obj)
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:594:21
|
578 | let map = fake_legacy_map(1);
| --- binding `map` declared here
579 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
594 | mem::forget(map);
| ^^^ move out of `map` occurs here
595 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:655:21
|
632 | let map_1 = fake_legacy_map(1);
| ----- binding `map_1` declared here
...
635 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
655 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
656 | mem::forget(map_2);
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:656:21
|
633 | let map_2 = fake_legacy_map(2);
| ----- binding `map_2` declared here
...
636 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
656 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:694:21
|
678 | let map = fake_btf_map(1);
| --- binding `map` declared here
679 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
694 | mem::forget(map);
| ^^^ move out of `map` occurs here
695 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:755:21
|
732 | let map_1 = fake_btf_map(1);
| ----- binding `map_1` declared here
...
735 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
755 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
756 | mem::forget(map_2);
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:756:21
|
733 | let map_2 = fake_btf_map(2);
| ----- binding `map_2` declared here
...
736 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
756 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
For more information about this error, try `rustc --explain E0505`.
error: could not compile `aya-obj` due to 6 previous errors
warning: build failed, waiting for other jobs to finish...
error: process didn't exit successfully: `/home/tamird/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo check --all-targets --manifest-path aya-obj/Cargo.toml --no-default-features` (exit status: 101)
This patch adds `user_regs_struct`.
riscv provides struct user_regs_struct instead of struct pt_regs to userspace.
After bindings generates the code, adding the riscv support in `bpf/aya-bpf/src/args.rs`
then aya-bpf can be built for riscv.
Keeping the `Pod` implementations and optional dependency on aya in
aya-log-common breaks the clippy checks (which are made on the entire
workspace).
The reason is that when different crates inside the workspace have the
same dependency with different features, that dependency is built only
once with the sum of features needed by all crates. It's **not** being
built separately with different feature sets.
That's why, before this change, aya-log-common was built once for the
entire workspace with `userspace` feature enabled. That made importing
aya-log-ebpf inside integration-ebpf impossible. The aya-log-common
build, with `userspace` feature enabled, was pulling std as a
dependency. Therefore, importing aya-log-ebpf inside integration-ebpf
resulted in including std and errors like:
```
error[E0152]: found duplicate lang item `panic_impl`
--> test/integration-ebpf/src/log.rs:23:1
|
23 | fn panic(_info: &core::panic::PanicInfo) -> ! {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: the lang item is first defined in crate `std` (which `aya` depends on)
```
This change fixes the problem by removing the `userspace` feature from
aya-log-common and moving the `Pod` implementations to aya-log.
This fixes `cargo build --all-features` by sidestepping the feature
unification problem described in The Cargo Book[0].
Add `cargo hack --feature-powerset` to CI to enforce that this doesn't
regress (and that all combinations of features work).
Since error_in_core is nightly-only, use core-error and a fake std
module to allow aya-obj to build without std on stable.
[0] https://doc.rust-lang.org/cargo/reference/features.html#feature-unification
Alessandro Decina
Mary
Tamir Duberstein
vadorovsky
dependabot[bot]
Kenjiro Nakayama
Everett Pompeii
Kabir Kwatra
Dave Tucker
Quentin JEROME