Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi > <jose.marchesi@xxxxxxxxxx> wrote: > > > clang generates BPF code with opcode 0x8d (BPF_CALL | BPF_X, which > > > it calls "callx"), when compiling with -O0 or -O1. Of course -O2 is > > > recommended, but if anyone later defines opcode 0x8d for anything > > > other than what clang means by it, it could cause problems. > > > > GCC also generates BPF_CALL|BPF_X also named callx, but only if the > > experimental -mxbpf option is passed to the compiler. > > > > I recommend this particular encoding to be specifically reserved for a > > future `call REG' for when/if a time comes when the BPF verifier > > supports some form of indirect calls. > > +1. > Same thinking from llvm pov. > CALL|X is what we will use when the kernel supports indirect calls. > I think it means we need to add a 'reserved' category to the spec. My reading of this thread is that there seems to be consensus that: 1) CALL|X should have an entry in the IANA registry with its own conformance group, 2) The intended meaning is understood, 3) clang and gcc both implement it already with the intended meaning, 4) The Linux kernel might support it someday. I'd propose we make it its own conformance group called "callx", which of course the Linux kernel does not yet support, but clang and gcc do. Rationale: * There may be other instructions reserved over time in the future so using a more specific name than just "reserved" is good since later additions require new groups with different names. * Defining it now with the meaning already implemented by clang & gcc means that no changes are needed later once Linux supports it. * ebpf-for-windows is likely to start supporting it in the very near future as a result of this thread. There is already a github pull request under review to add support for it in the PREVAIL verifier. Dave
