Re: Bcc on 32-bit ARM

Yonghong Song

On Fri, Oct 13, 2017 at 5:53 AM, Adrian Szyndela via iovisor-dev
<iovisor-dev@...> wrote:

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@...> wrote:

- return type of bpf_pseudo_fd is 'u64', and it is passed to functions
take pointers; the compiler generates 'trunc' in IR for this, which
shift-left + shift-right in final bpf code; and bpf verifier does not
it when pointers are shifted. We worked it around by changing return type
bpf_pseudo_fd/llvm.bpf.pseudo from 'u64' to 'void *' - both in bcc

and llvm

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:

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

Any thoughts how to handle this?
All these are valid. For certain program types e.g., networking where pt_regs
are not needed, you can already use -target bpf in clang. Check

Since currently we do not have good solutions for pt_regs when "clang
-target bpf" is
used, let us stick to the approach "clang -target arm"/"llc -target bpf".

iovisor-dev mailing list

Join to automatically receive all group messages.