Tomislav Novak

Considering that BPF is a 64-bit ISA, are there any fundamental issues with bpftrace doing 32-bit pointer loads/stores I may have missed? There's one corner case I've hit where adding...

> I still need to think some more about using 32-bit pointers inside 64-bit BPF - I'll have to try and get myself a 32-bit ARM environment to play around...

Thanks for the detailed review, @BurntBrunch! > I wonder if we can gain more confidence in this approach by requiring that AST nodes with pointer types have corresponding llvm pointer...

> If we keep everything in bpf land to 64-bit, then the boundary where we care about pointer size and type conversions is only the probes into kernel/user memory and...

I've rewritten this to keep the internal `Type::pointer` 8 bytes long, but use the correct pointer size when reading pointer types from kernel/user memory (approach 2 described in earlier comments)....

> Ideally, our solution would work for all these probe types and not just `interval`. We'll want to avoid the situation where a long-running profile gradually loses visibility into more...

@pkropachev: that trace looks correct -- first few `bpf` syscalls are from bpftrace checking which features are available, and then finally the generated BPF code is successfully loaded (if you...

> perf_event_open fails at a further stage, since THUMB is not supported in current kernel Right, the kernel doesn't (yet) support probing Thumb code. At the very least, I believe...