Open kyeongmincho opened 9 years ago
Thanks for trying this. This is indeed a bug, I am looking into it now.
Some of the code generation issues are fixed with the above commit, but your example will still fail due to a couple of reasons:
= {}
in the new_data initializer.the following: leaf->flag[flags % NUM_GFP_FLAG]++; is indeed challenging for verifier. It would require quite sophistication to prove that above line will never trigger out-of-bounds.
On Thu, Oct 1, 2015 at 12:00 PM, Brenden Blanco notifications@github.com wrote:
Some of the code generation issues are fixed with the above commit, but your example will still fail due to a couple of reasons:
Loops are not allowed. The kernel BPF verifier will not accept any loops in the bytecode, so unless LLVM decides to unroll the for loop that you have as an optimization, this won't work. Since you are just zeroing out the array, I would advise to just put a = {} in the new_data initializer.
LLVM is generating unverifiable code for the leaf->flag[XX]++ lines of code. This is not something BCC can easily address, maybe @yonghong-song has some ideas how to work around this?
— Reply to this email directly or view it on GitHub.
There are two issues compiler/verifier need to address for this test case. . issue #234 , which I am currently working on. . array out of bound analysis as @4ast indicated above. For verifier, there is no array any more. so just some pointer arithmetic, so it make analysis even harder. I have not got an workaround yet.
For the loop, for (int i = 0; i < NUM_GFP_FLAG; ++i) new_data.flag[i] = 0;
Compiler actually fully unrolls it, so it is not a problem in this particular case.
Hi, I made a simple bpf program and there are two errors which i think are kind of bugs. First, I don't know why an variable whose type is
size_t
cannot be sum with the othersize_t
variable. Second, When the compiler handles an array, it causes an grammatical error. In the process of compiling that array, i think, it breaks some syntaxes. Please see below and give me a thought:'simple.c' has a bpf function that crawls data about the system call
__kmalloc
and 'simple.py' prints that data.simple.c
simple.py
error: