You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Multiple programs in the repository, including twostackvars, and ovs/datapath.o, sections: [tail-1, tail-4, tail-5, tail-7, tail-8, tail-11, tail-13] dead with two stack pointers (at different offsets) joined. It is usually followed by a lookup for numeric value at the stack pointer offset in the joined basic block. It is likely to fail because if the numbers were at different offsets, they are forgotten during join. For this purpose, the eBPF (zoneCrab domain) has stack_numeric_size variable with each stack variable that computes how many bytes after the stack_offset, the bytes are numeric. In eBPF, the check succeeds. However, type domain does not, for the given benchmarks.
Link to pull request for stack_numeric_size-related discussion: vbpf#292
The text was updated successfully, but these errors were encountered:
Multiple programs in the repository, including twostackvars, and
ovs/datapath.o, sections: [tail-1, tail-4, tail-5, tail-7, tail-8, tail-11, tail-13]
dead with two stack pointers (at different offsets) joined. It is usually followed by a lookup for numeric value at the stack pointer offset in the joined basic block. It is likely to fail because if the numbers were at different offsets, they are forgotten during join. For this purpose, the eBPF (zoneCrab
domain) hasstack_numeric_size
variable with each stack variable that computes how many bytes after thestack_offset
, the bytes are numeric. In eBPF, the check succeeds. However,type
domain does not, for the given benchmarks.Link to pull request for
stack_numeric_size
-related discussion: vbpf#292The text was updated successfully, but these errors were encountered: