`Option<NonZeroUsize>` is guaranteed to have the same size as `usize`,
which is not guarnateed for `Result`. This is a minor optimization, but
also results in simpler code.
Implements running integration tests on multiple VMs with arbitrary
kernel images using `cargo xtask integration-test vm ...`.
This changes our coverage from 6.2 to 6.1 and 6.4.
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>
Some of these functions fail to compile when not inlined, so we should
be explicit.
Before deciding on this approach I tried various ways of making all
these functions #[inline(never)] to save instructions but I ran into
blockers:
- These functions currently return Result, which is a structure. This is
not permitted in BPF.
- I tried inventing a newtype that is a #[repr(transparent)] wrapper of
u16, and having these functions return that; however it seems that
even if the object code is legal, the verifier will reject such
functions because the BTF (if present, and it was in my local
experiments) would indicate that the return is a structure.
- I tried having these functions return a plain u16 where 0 means error,
but the verifier still rejected the BTF because the receiver (even if
made into &self) is considered a structure, and forbidden.
We can eventually overcome these problems by "lying" in our BTF once
support for it matures in the bpf-linker repo (e.g. Option<NonZeroU16>
should be perfectly legal as it is guaranteed to be word-sized), but we
aren't there yet, and this is the safest thing we can do for now.
- Remove `TagLenValue`; this type has a single method, which is now a
function.
- Remove generics from `TagLenValue::write` (now `write`). The tag is
always `u8`, and the value is always a sequence of bytes.
- Replace slicing operations which can panic with calls to `get` which
explicit check bounds.
The struct_flavors test previously expected the same thing with and
without relocations. It now expects different values.
Also rename an enum variant "u64" to "S64". This was a typo. Turns out
that U32 is a type that exists in kernel headers, so all enum values are
suffixed with "_VAL".
Remove stdlib.h and the call to exit(). This alone makes the test fail
with a poisoned relocation. Bringing over the map definition makes the
test work again.
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.
This commit fixes the (func|line)_info when we have multiple programs in
the same section. The integration test reloc.bpf.c serves as our test
case here. This required filtering down the (func|line)_info to only
that in scope of the current symbol + then adjusting the offets to
appease the kernel.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
For unclear reasons, two of the integration tests related to uprobes
were resolving a symbol in libc. The integration-test binary can be
built statically, in which case it would not load or reference libc.
Statically linking the integration tests and running them in a VM
without a userland is a convenient mechanism to exercise the tests
against different kernel versions.
The fact that the statically linked integration-test binary does not
load libc is not the only reason these tests failed in such an
environment. In fact, the logic to look in the process's memory
maps was not running (because no pid was being passed).
Separate logic to determine which object file to use when attempting
to resolve a symbol for attaching a uprobe changes its behavior based
on whether that target is an absolute path. If the target is not an
absolute path, the code searches through the LdSoCache. This cache does
not always exist in linux systems; when an attach call is made with a
relative path target and there is no /etc/ld.so.cache file, the attach
call will fail. This commit does not change that behavior, it merely
sidesteps it.
The function is extracted so that a test could be written. This test is
valid on linux-gnu targets, and it doesn't need any special privileges.
This is in anticipation of removing the code that uses this functionality
(seemingly incidentally) from integration tests.
Tamir Duberstein
Alessandro Decina
Addison Crump
Dave Tucker
Andrés Medina
Addison Crump
ajwerner