The helpers always return a signed 64-bit r0 value, but the JIT that
translates eBPF into native instructions differs by architecture. On
x86_64 the generated code writes the helper result into a 64-bit
register, so the CPU sign-extends negative errnos automatically. On
aarch64 the JIT frequently uses 32-bit operations (w0) when copying the
helper return and only zero-extends into the upper half of x0.
That results in broken errno codes on aarch64. For example, when a map
operation returns `-ENOENT`, which is supposed to be -2, the i64
representation yields something like `0x0000_0000_FFFF_FFFE`
(4294967294) instead of -2. In short: the ARM64 JIT doesn’t preserve the
sign in the upper half of the 64-bit register, and the error code has to
be cast to a 32-bit integer to make the sign visible.
This makes it awkward for users, because that behavior prevents simply
comparing helper error codes with constants like `libc::ENOENT` without
manual casts.
Given that the maximum error code limit `MAX_ERRNO` in the kernel is
4095, which fits in a 32-bit integer, coerce the error codes to be `i32`
and make all helpers return `Result<T, i32>`.
Before this change, Aya supported only legacy BPF map definitions, which
are instances of the `bpf_map_def` struct and end up in the `maps` ELF
section.
This change introduces a BTF map definition for arrays, with custom
structs indicating the metadata of the map, which end up in the `.maps`
section.
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
In practice this will forbid unused dependencies because we run clippy
with `--deny warnings`.
Workspace lints is a nice place to ratchet up lints through the codebase
all at once and consistently.
Change FromRawTracepointArgs::arg to return T rather than *const T which
seems to have been returning a dangling pointer.
Arguably this is not strictly necessary; edition 2024 seems to be
focused on increased strictness around unsafe code which doesn't unlock
new functionality for our users. That said, this work revealed an
apparent bug (see above) that we wouldn't otherwise catch due to
allow-by-default lints.
Provide an `arg()` method in `RawTracepointArgs` wrapper of
`bpf_raw_tracepoint_args` and also in `RawTracepointContext`, so
it's directly available in raw tracepoint programs.
The methods and traits implemented here are unsafe. There is no
way to reliably check the number of available arguments, so
requesting a non-existing one leads to undefined behavior.
