> 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. > > On the BPF_MSH thread at > https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/ > Alexei wrote regarding BPF_ABS and BPF_IND: >> DW never existed in classic bpf, so abs/ind never had DW flavor. >> If some assembler/compiler decided to "support" them it's on them. >> The standard must not list such things as deprecated. They never existed. > > Technically BPF_CALL | BPF_X never existed either, so can be omitted from > the IANA registry. But given the widespread deployment of clang's > use, and the WG charter statement: >> The BPF working group is initially tasked with documenting the existing >> state of the BPF ecosystem > I could see a potential argument to list it as reserved or something. > > Today, the document doesn't reserve it, so it's open for future use for any > purpose. I just wanted to verify that the WG is ok with not listing it > in the IANA registry, given the above information. > > Dave
