| Message ID | 20230706222020.268136-2-hawkinsw@obs.cr (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | BPF |
| Headers | show |
| Series | Describe stack contents for function calls | expand |
| Context | Check | Description |
|---|---|---|
| bpf/vmtest-bpf-next-PR | success | PR summary |
| bpf/vmtest-bpf-next-VM_Test-1 | success | Logs for ShellCheck |
| bpf/vmtest-bpf-next-VM_Test-3 | pending | Logs for build for s390x with gcc |
| bpf/vmtest-bpf-next-VM_Test-4 | success | Logs for build for x86_64 with gcc |
| bpf/vmtest-bpf-next-VM_Test-5 | success | Logs for build for x86_64 with llvm-16 |
| bpf/vmtest-bpf-next-VM_Test-6 | success | Logs for set-matrix |
| bpf/vmtest-bpf-next-VM_Test-2 | success | Logs for build for aarch64 with gcc |
| netdev/tree_selection | success | Not a local patch |
On Thu, Jul 6, 2023 at 3:20 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > The execution of every function proceeds as if it has access to its own > stack space. > > Signed-off-by: Will Hawkins <hawkinsw@obs.cr> > --- > 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. For example x86-64 JIT maps BPF R10 to RBP. Yet there is -fomit-frame-pointer. So we might very well do something like that in the future.
On Thu, Jul 6, 2023 at 7:32 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Thu, Jul 6, 2023 at 3:20 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > The execution of every function proceeds as if it has access to its own > > stack space. > > > > Signed-off-by: Will Hawkins <hawkinsw@obs.cr> > > --- > > 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). Sorry if I am being dense and/or naive. Sincerely, Will > For example x86-64 JIT maps BPF R10 to RBP. > Yet there is -fomit-frame-pointer. > So we might very well do something like that in the future.
On Thu, Jul 6, 2023 at 5:46 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > On Thu, Jul 6, 2023 at 7:32 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Thu, Jul 6, 2023 at 3:20 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > > > The execution of every function proceeds as if it has access to its own > > > stack space. > > > > > > Signed-off-by: Will Hawkins <hawkinsw@obs.cr> > > > --- > > > 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@mail.gmail.com/ tldr: it's a mess. We should remove 'Registers and calling convention' section from instruction-set.rst
On Thu, Jul 6, 2023 at 8:48 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Thu, Jul 6, 2023 at 5:46 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > On Thu, Jul 6, 2023 at 7:32 PM Alexei Starovoitov > > <alexei.starovoitov@gmail.com> wrote: > > > > > > On Thu, Jul 6, 2023 at 3:20 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > > > > > The execution of every function proceeds as if it has access to its own > > > > stack space. > > > > > > > > Signed-off-by: Will Hawkins <hawkinsw@obs.cr> > > > > --- > > > > 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@mail.gmail.com/ > > 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
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. + Instruction encoding ====================
The execution of every function proceeds as if it has access to its own stack space. Signed-off-by: Will Hawkins <hawkinsw@obs.cr> --- Documentation/bpf/instruction-set.rst | 5 +++++ 1 file changed, 5 insertions(+)