On Wed, Feb 22, 2023 at 2:23 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > [...] > > > +Helper functions > > > +~~~~~~~~~~~~~~~~ > > > + > > > +Helper functions are a concept whereby BPF programs can call into a > > > +set of function calls exposed by the runtime. Each helper function > > > +is identified by an integer used in a ``BPF_CALL`` instruction. > > > +The available helper functions may differ for each program type. > > > + > > > +Conceptually, each helper function is implemented with a commonly > > > +shared function signature defined as: > > > + > > > + u64 function(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5) > > > + > > > +In actuality, each helper function is defined as taking between 0 and > > > +5 arguments, with the remaining registers being ignored. The > > > +definition of a helper function is responsible for specifying the > > > +type (e.g., integer, pointer, etc.) of the value returned, the number of > > arguments, and the type of each argument. > > > > Above is correct, but it aims to describe the calling convention which should > > be done in a separate BPF psABI doc and not in instruction-set.rst. > > And if we start describing calling convention we should talk about promotion > > rules, sign extensions, expectations for return values, for passing structs by > > value, etc. > > The instruction itself requires defining the concept of a helper function, Not really. BPF_CALL instruction doesn't have to define what it's calling and how the call is being made. Typical cpu will define CALL insn as: 1. pushes the return address on the stack. 2. changes IP to the call destination That's it. Mechanics of CALL have no overlap with calling convention. Different languages and operating systems can do it differently. BPF ISA doc should describe mechanics of instructions only. > so is the > text in question the part starting with "Conceptually," down to the end of the > quoted text? Right, that part doesn't belong in BPF ISA doc. Even "Each helper function is identified by an integer used in a ``BPF_CALL`` instruction." arguably belongs in psABI, since it's a bpf's flavor of relocations. Other cpus do it in ELF relocations while bpf does it inline as part of instruction encoding. That is not an ISA. It's a protocol between user and kernel. We just happen to use bits in instruction to indicate relocation that kernel has to perform before executing call insn. At the end JITs will map BPF_CALL insn one to one to CPU call insn on architectures where calling conventions match. > Since there is no separate BPF psABI document (and I'm not sure the scope of > that document myself) can we put it here for now and move it when that doc > is created? If not, what part of the text above would be in a separate document? BPF psABI should look like: https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf Ours will be shorter, hopefully. We haven't defined a bunch of things yet. Like how to pass 6th argument.
