On Thu, Jul 6, 2023 at 8:48 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Jul 6, 2023 at 5:46 PM Will Hawkins <hawkinsw@xxxxxx> wrote: > > > > On Thu, Jul 6, 2023 at 7:32 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > On Thu, Jul 6, 2023 at 3:20 PM Will Hawkins <hawkinsw@xxxxxx> wrote: > > > > > > > > The execution of every function proceeds as if it has access to its own > > > > stack space. > > > > > > > > Signed-off-by: Will Hawkins <hawkinsw@xxxxxx> > > > > --- > > > > Documentation/bpf/instruction-set.rst | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst > > > > index 751e657973f0..717259767a41 100644 > > > > --- a/Documentation/bpf/instruction-set.rst > > > > +++ b/Documentation/bpf/instruction-set.rst > > > > @@ -30,6 +30,11 @@ The eBPF calling convention is defined as: > > > > R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if > > > > necessary across calls. > > > > > > > > +Every function invocation proceeds as if it has exclusive access to an > > > > +implementation-defined amount of stack space. R10 is a pointer to the byte of > > > > +memory with the highest address in that stack space. The contents > > > > +of a function invocation's stack space do not persist between invocations. > > > > > > Such description belongs in a future psABI doc. > > > instruction-set.rst is not a place to describe how registers are used. > > > > Thank you for the feedback! > > > > How does your comment square with the immediately preceding > > description in the document that says: > > > > R10: read-only frame pointer to access stack > > > > (among the description of how other registers are used during function calls). > > See > https://lore.kernel.org/bpf/CAADnVQ+gLnsOVj9s4zpAP6+U6nFHYm6GVZ1FteRac=ZaJvpfDg@xxxxxxxxxxxxxx/ > > tldr: it's a mess. > We should remove 'Registers and calling convention' section from > instruction-set.rst Understood. I am working closely (at least I would like to think that it's closely) with Dave and have been following that thread attentively. I will help with documentation and writing in whatever way I can. Will
