Re: FW: BPF_PSEUDO_CALL question

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Apr 19, 2019 at 11:16:31AM +0000, Ananyev, Konstantin wrote:
> 
> 
> > > > >
> > > > > Hi Alexei,
> > > > > I posted the question below on llvm-dev mailing list, but there is no answer so far.
> > > > > As you seems the author of BPF_PSEUDO_CALL in LLVM (and linux kernel) thought might
> > > > > be you know the answer?
> > > > > I looked through the patches, but didn't spot anything myself.
> > > > > Thanks
> > > > > Konstantin
> > > > >
> > > > > -----Original Message-----
> > > > > From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] On Behalf Of Ananyev, Konstantin via llvm-dev
> > > > > Sent: Wednesday, April 10, 2019 7:37 PM
> > > > > To: llvm-dev@lists.llvm.org
> > > > > Subject: [llvm-dev] BPF_PSEUDO_CALL question
> > > > >
> > > > >
> > > > > Hi everyone,
> > > > > with clang 6.0 and onwards, for the following code:
> > > > > $ cat t6.c
> > > > >
> > > > > #include <stdint.h>
> > > > >
> > > > > extern int ffx1(const void *p);
> > > > >
> > > > > uint64_t entry(const void *p)
> > > > > {
> > > > >         return ffx1(p);
> > > > > }
> > > > >
> > > > > clang -O2  -target bpfel -c t6.c
> > > > > generates for the call BPF_PSEUDO_CALL instruction:
> > > > > entry:
> > > > >        0:       85 10 00 00 ff ff ff ff         call -1
> > > > >        1:       67 00 00 00 20 00 00 00         r0 <<= 32
> > > > >        2:       c7 00 00 00 20 00 00 00         r0 s>>= 32
> > > > >        3:       95 00 00 00 00 00 00 00         exit
> > > > >
> > > > > Is there any way to force clang to generate proper BPF_CALL instruction,
> > > > > i.e: 85 00 00 00 ff ff ff ff (as it did in older versions)?
> > > >
> > > > older version of llvm generated broken code.
> > > > there are only two call flavors:
> > > > - call imm -> calling particular kernel helper where imm==helper_id
> > >
> > > Ok but in the example above, is it possible tell to the llvm that
> > > ffx1() is actually a kernel helper with id==X?
> > 
> > here is how it works for helpers:
> > static void *(*bpf_map_lookup_elem)(void *map, const void *key) =
> >         (void *) BPF_FUNC_map_lookup_elem;
> > 
> > User space can hack similar thing for any integer and any name.
> 
> Thanks a lot.
> Yes, such approach would work.
> Though it means that user will need to define exact id for the each  helper function
> and keep it always in sync between bpf programs and bpf execution environment. 
> Probably not a big deal for kernel when all helpers are well defined and restricted,
> but might become messy for user-space where each app might want to have it's
> own set of helpers.
> My thought was - might be it is possible to say to llvm that it is a helper function
> but with unknown id that will be resolved dynamically at bpf load time.

I'm not sure what exactly you're proposing.
For local functions llvm will generate relative offset with pseudo_call mark.
That is api and cannot be changed.
Support for calling external functions is currently half way done,
since relocations are there, but could be buggy, since
there is no kernel/libbpf support for it yet.