This commit adds:
- A probe to see if the ENUM64 feature is supported
- Fixups for the use of signed enums, or enum64 types
on systems where enum64 is not supported
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
The BTF we're working on is Cow anyway so modifying in-place is fine.
All we need to do is store some information before we start our
mutable iteration to avoid concurrently borrowing types both mutably and
immutably.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Rather than creating an empty vector and iteratively appending - which
might induce intermediate allocations - create an ExactSizeIterator and
collect it into a vector, which should produce exactly one allocation.
Wrap verifier logs in a newtype whose `Debug` impl emits unescaped
newlines. This improves ergonomics in tests where we `Result::unwrap()`
those load errors; when these fail today they emit the errors with
newlines escaped, making them incredibly difficult to read.
This commit adds a new probe for bpf_attach_cookie, which would be used
to implement USDT probes. Since USDT probes aren't currently supported,
we this triggers a dead_code warning in clippy.
There are cases where exposing FEATURES - our lazy static - is actually
helpful to users of the library. For example, they may wish to choose to
load a different version of their bytecode based on current features.
Or, in the case of an orchestrator like bpfd, we might want to allow
users to describe which features their program needs and return nice
error message is one or more nodes in their cluster doesn't support the
necessary feature set.
To do this without breaking the API, we make all the internal members of
the `Features` and `BtfFeatures` structs private, and add accessors for
them. We then add a `features()` API to avoid leaking the
lazy_static.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
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.
* 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
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
This fix the following issues:
- Previously the DATASEC name wasn't sanitized resulting on "Invalid
name" returned by old kernels.
- The newly created BTF struct had a size of 0 making old kernels refuse
it.
This was tested on Debian 10 with kernel 4.19.0-21.
The crate has few libstd dependencies. Since it should be platform-
independent in principle, making it no_std like the object crate would
seem reasonable.
However, the feature `error_in_core` is not yet stabilized, and the
thiserror crate currently offers no no_std support. When the feature
no_std is selected, we enable the `error_in_core` feature, switch to
thiserror-core and replace the HashMap with the one in hashbrown.
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: #473