Move BpfError::UnsupportedMap into MapError and add a map_type field to
the error.
Update the `allow_unsupported_maps` function comment.
Update the logic to check if any unsupported maps are being used. More
specifically only search a program's maps if `allow_unsupported_maps` is
set and then use the iter function `try_for_each` with a match statement
which allows us to return the inner map type if it's unsupported.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
Just because aya doesn't support working with some map
types doesn't mean we should't allow them to be loaded.
Add a new `Unsupported` map type to facilitate this,
Next add a user configurable option `allow_unsupported_maps()`
which can be called against the `bpfLoader`. Additionally
add a nice warning log message when a program is being loaded
by Aya and contains an unsupported map type.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
This patch introduces `pt_regs` handling in aya-bpf/args.rs
for the riscv64 architecture. The current CI is disabled
for riscv64 because this implementation is missing.
These two functions are needed because kernel symbols representing
syscalls have architecture-specific prefixes.
These are the equivalent of bcc's get_syscall_fnname and
get_syscall_prefix.
Solves: #534
Before this change:
```
error[E0382]: use of moved value: `no_copy`
--> test/integration-ebpf/src/log.rs:35:9
|
33 | let no_copy = NoCopy {};
| ------- move occurs because `no_copy` has type `NoCopy`, which does not implement the `Copy` trait
34 |
35 | debug!(&ctx, "{:x}", no_copy.consume());
| ^^^^^^^^^^^^^^^^^^^^^-------^---------^
| | | |
| | | `no_copy` moved due to this method call
| | use occurs due to use in closure
| value used here after move
|
note: `NoCopy::consume` takes ownership of the receiver `self`, which moves `no_copy`
--> test/integration-ebpf/src/log.rs:28:24
|
28 | fn consume(self) -> u64 {
| ^^^^
= note: this error originates in the macro `debug` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0382`.
error: could not compile `integration-ebpf` (bin "log") due to previous error
```
This fix aya wrong logic causing non entrypoint functions to not have
any BTF relocations working.
Also fix missing section_offset computation for instruction offset in
multiple spots.
Files changed:
M aya-obj/src/generated/btf_internal_bindings.rs
M aya-obj/src/generated/linux_bindings_aarch64.rs
M aya-obj/src/generated/linux_bindings_armv7.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
aya-log-ebpf-macros was failing to compile because it was referencing
a couple of `DisplayHint` variants that no longer exist. These were
removed in #599.
```
Compiling aya-log-ebpf-macros v0.1.0 (/home/robert/aya/aya-log-ebpf-macros)
error[E0599]: no variant or associated item named `Ipv4` found for enum `DisplayHint` in the current scope
--> aya-log-ebpf-macros/src/expand.rs:93:22
|
93 | DisplayHint::Ipv4 => parse_str("::aya_log_ebpf::macro_support::check_impl_ipv4"),
| ^^^^ variant or associated item not found in `DisplayHint`
error[E0599]: no variant or associated item named `Ipv6` found for enum `DisplayHint` in the current scope
--> aya-log-ebpf-macros/src/expand.rs:94:22
|
94 | DisplayHint::Ipv6 => parse_str("::aya_log_ebpf::macro_support::check_impl_ipv6"),
| ^^^^ variant or associated item not found in `DisplayHint`
For more information about this error, try `rustc --explain E0599`.
```
Having separate format hints and tokens per IP address family is
unnecessary, since they are represented by different types and we handle
format hints for each type separately. So we can just have one format
hint.
Also, we should be consistent with the format strings grammar in
Rust[0]. The `type` token, which is mapped to formatting traits, usually
consists of one letter[1] (and optional `?` for `Debug` trait, but that
doesn't matter for us). It shouldn't consist of multiple letters. Our
`:ipv4` and `:ipv6` tokens were clearly breaking that convention, so we
should rather switch to something with one letter - hence `:i`.
[0] https://doc.rust-lang.org/std/fmt/#syntax
[1] https://doc.rust-lang.org/std/fmt/#formatting-traits
* use the hdr_len of BTF.ext sections rather than size of struct
Otherwise this will erroneously fail on older btf_ext_header that have
less fields than the bindgen'd struct
* do not attempt to load a BTF object that has no types
* add tests
* fix: hdr_len i32 -> u32
* guard against a bigger header in the future
* use separate unsafe blocks
* simplify writing to zero'd out header
* merge safe block and address typo
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.
Mary
Mary
Andrew Stoycos
dependabot[bot]
Kenjiro Nakayama
Alessandro Decina
Federico Ponzi
Tamir Duberstein
Alexis (Poliorcetics) Bourget
alessandrod
Robert Bartlensky
William Batista
Michal Rostecki
Andrés
Hanaasagi
Shubham Jain