Alastair Robertson

Also tests with just: `EXPECT Attaching 1 probe...`. These only check that the program can run and not that its output is correct.

Once this is done, we can clean up the `dereference_if_needed` stuff from #3094. It would be better as a separate pass that sits between type propagation and the true semantic...

This bug appears to caused by this code: https://github.com/bpftrace/bpftrace/blob/4c8b262aed6399a04126d2f5199d0d588924e6d2/src/ast/passes/codegen_llvm.cpp#L2816-L2819 Variables which "needMemcpy" are passed around as a reference to their stack location as an `AllocaInst`: https://github.com/bpftrace/bpftrace/blob/4c8b262aed6399a04126d2f5199d0d588924e6d2/src/ast/passes/codegen_llvm.cpp#L1426-L1428 The issue is limited...

Agreed that proper lifetime analysis seems to be the way forwards. LLVM (at least back in the pre 4.0 days) doesn't do lifetime analysis by default - that's why we...

I managed to get Clang to emit lifetime markers: https://godbolt.org/z/59az7M9Ko Code for reference: ```c void foo(int *p) { int a = 0; *p += (int)&a; int b = 0; *p...

I don't think there's a bug here. The error message is correct in telling you that you're trying to access the field `f_inode` on a `struct file *`. Here's the...

Let's try and get a simpler repro. Does this script still fail for you? ``` #include BEGIN { $x = (struct file*)0; $x->f_inode; } ``` How about this one without...

> IIRC if you do any `#include` then BTF is not processed Yeah, I think this is the case. The first case failing and the second passing suggests a problem...

Related to #2684. This is the kind of use-case that we're hoping range-deletes (#2922) will help with: record lots of data and then selectively delete parts when it's later determined...

Thanks for opening this ticket. It's a long-standing issue but it looks like we didn't have anything tracking it before. There have been attempts to fix this in the past...