W dniu 04.10.2017 o 21:14, Y Song pisze:
On Wed, Oct 4, 2017 at 3:24 AM, Adrian Szyndela via iovisor-dev
<iovisor-dev@lists.iovisor.org> wrote:
- return type of bpf_pseudo_fd is 'u64', and it is passed to functions that
take pointers; the compiler generates 'trunc' in IR for this, which becomes
shift-left + shift-right in final bpf code; and bpf verifier does not like
it when pointers are shifted. We worked it around by changing return type of
bpf_pseudo_fd/llvm.bpf.pseudo from 'u64' to 'void *' - both in bcc
(https://github.com/aszyndela/bcc/commit/8eb8fb2e265b93d38c1ad53efcb7da8883a3d643)
and llvm
(include/llvm/IR/IntrinsicsBPF.td):
def int_bpf_pseudo : GCCBuiltin<"__builtin_bpf_pseudo">,
- Intrinsic<[llvm_i64_ty], [llvm_i64_ty, llvm_i64_ty]>;
+ Intrinsic<[llvm_ptr_ty], [llvm_i64_ty, llvm_i64_ty]>;
Obviously we don't know what we're doing, but at least it works for us.
This should work as well. essentially bpf_pseudo tries to convert a
load map_id to load_imm64 address. So its return value is indeed a ptr.
I asked about it on llvm-dev and the only suggestion I got so far is to
set bpf target for clang:
https://lists.llvm.org/pipermail/llvm-dev/2017-October/118149.html
And it makes sense...
We can easily get into trouble when we mix two targets in the process.
For example, it looks like sizeofs are computed at the "clang" stage,
but actual sizes of some types are "known" at the "llc" stage.
However, switching to bpf target for the whole process takes away
convenience and maintainability: we can't rely on including kernel
headers anymore. So we have to craft everything we need by hand,
including struct pt_regs...
Any thoughts how to handle this?
_______________________________________________
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
