The recommendation (coming from rust-lang/rust#130062) for Linux hosts
is using C compiler driver as a linker, which is able to find
system-wide libraries. Using linker binaries directly in `-C linker`
(e.g. `-C linker=rust-lld`) often results in errors like:
```
cargo:warning=error: linking with `rust-lld` failed: exit status: 1ger, ppv-lite86, libc...
cargo:warning= |
cargo:warning= = note: LC_ALL="C" PATH="/home/vadorovsky/.rustup/toolchains/stable-x86_64-un
cargo:warning= = note: rust-lld: error: unable to find library -lgcc_s
cargo:warning= rust-lld: error: unable to find library -lc
cargo:warning=
cargo:warning=
cargo:warning=
cargo:warning=error: aborting due to 1 previous error
```
Not touching the linker settings is usually the best approach for Linux
systems. Native builds pick up the default C toolchain. Cross builds
default to GCC cross wrapper, but that's easy to supress with clang
and lld using RUSTFLAGS.
However, `-C linker=rust-lld` still works the best on macOS, where
Rust toolchains come with unwinder and runtime and there is usually no
need to link system libraries. Keep setting it only for macOS.
Fixes#907
This removes the fake std module in aya-obj which is no longer needed as
thiserror now properly supports no_std.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
The loader should fill bss maps with zeros according to the size of the
ELF section.
Failure to do so yields weird verifier messages as follows:
```
cannot access ptr member ops with moff 0 in struct bpf_map with off 0 size 4
```
Reference to this in the cilium/ebpf code is here [1].
I could not find a reference in libbpf.
1: d0c8fc1937/elf_reader.go (L1159-L1165)
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Users have reported issues with programs failing the verifier when they
are attempting to read or write to variables that the compiler places in
the .bss section. Add a test that places variables in each section and
exercises read and write operations on them.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
I did this for arm64 because we'd get a black screen without it but I
have now confirmed that console=ttyAMA0 solves that problem.
I don't remember why I did it for x86.
Update libbpf to 80b16457cb23db4d633b17ba0305f29daa2eb307
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_powerpc64.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/src/generated/linux_bindings_s390x.rs
M aya-obj/src/generated/linux_bindings_x86_64.rs
Adds the following to codegen:
- `bpf_cgroup_iter_order`: used in `bpf_link_info.iter.group.order`
- `NFPROTO_*`: used in `bpf_link_info.netfilter.pf`
- `nf_inet_hooks`: used in `bpf_link_info.netfilter.hooknum`
Include `linux/netfilter.h` in `linux_wrapper.h` for `NFPROTO_*` and
`nf_inet_hooks` to generate.
This commit adds the initial support for TCX
bpf links. This is a new, multi-program, attachment
type allows for the caller to specify where
they would like to be attached relative to other
programs at the attachment point using the LinkOrder
type.
Signed-off-by: astoycos <astoycos@redhat.com>
Co-authored-by: Andre Fredette <afredette@redhat.com>
Co-authored-by: Dave Tucker <dave@dtucker.co.uk>
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
```
error: the following explicit lifetimes could be elided: 'data, 'file
--> aya-obj/src/obj.rs:1083:6
|
1083 | impl<'data, 'file, 'a> TryFrom<&'a ObjSection<'data, 'file>> for Section<'a> {
| ^^^^^ ^^^^^ ^^^^^ ^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
```
Instead of relying on Homebrew for macOS (which ships older LLVM
versions) and `apt.llvm.org` for Linux (which often has bugs at the
packaging level), we now use the tarball from Rust CI to provide
`libLLVM`. This ensures it always matches the version used by the latest
Rust nightly.
This removes our reliance on homebrew shipping LLVM versions matching
those used by rustc.
Michal Rostecki
Tamir Duberstein
dependabot[bot]
tamird
Dave Tucker
dave-tucker
Tyrone Wu
astoycos
GrigorenkoPV
Vladimir Petrzhikovskii