Message-ID: <CAEf4BzZYOrXQFtVbqhw7PagzT6VhfM5LRV93cLuzABy8eHWyqw@mail.gmail.com>
Date:   Thu, 19 Dec 2019 16:02:27 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH RFC bpf-next 2/3] libbpf: Handle function externs and
 support static linking

On Thu, Dec 19, 2019 at 6:29 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> From: Toke Høiland-Jørgensen <toke@...hat.com>
>
> This adds support for resolving function externs to libbpf, with a new API
> to resolve external function calls by static linking at load-time. The API
> for this requires the caller to supply the object files containing the
> target functions, and to specify an explicit mapping between extern
> function names in the calling program, and function names in the target
> object file. This is to support the XDP multi-prog case, where the
> dispatcher program may not necessarily have control over function names in
> the target programs, so simple function name resolution can't be used.
>
> The target object files must be loaded into the kernel before the calling
> program, to ensure all relocations are done on the target functions, so we
> can just copy over the instructions.
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
> ---

A bunch of this code will change after you update to latest Clang with
proper type info for extern functions. E.g., there shouldn't be any
size/alignment for BTF_KIND_FUNC_PROTO, it's illegal. But that
Yonghong already mentioned.

As for the overall approach. I think doing static linking outside of
bpf_object opening/loading is cleaner approach. If we introduce
bpf_linker concept/object and have someting like
bpf_linked__new(options) + a sequence of
bpf_linker__add_object(bpf_object) + final bpf_linker__link(), which
will produce usable bpf_object, as if bpf_object__open() was just
called, it will be better and will allow quite a lot of flexibility in
how we do things, without cluttering bpf_object API itself.
Additionally, we can even have bpf_linker__write_file() to emit a
final ELF file with statically linked object, which can then be loaded
through bpf_object__open_file (we can do the same for in-memory
buffer, of course). You can imagine LLC some day using libbpf to do
actual linking of BPF .o files into a final BPF executable/object
file, just like you expect it to do for non-BPF object files. WDYT?

Additionally, and seems you already realized that as well (judging by
FIXMEs), we'll need to merge those individual objects' BTFs and
deduplicate them, so that they form coherent set of types. Adjusting
line info/func info is mandatory as well.

Another thing we should think through is sharing maps. With
BTF-defined maps, it should be pretty easy to have declaration vs
definiton of maps. E.g.,

prog_a.c:

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 123);
    ... and so on, complete definition
} my_map SEC(".maps");

prog_b.c:

extern struct {
    ... here we can discuss which pieces are necessary/allowed,
potentially all (and they all should match, of course) ...
} my_map SEC(".maps");

prog_b.c won't create a new map, it will just use my_map from prog_a.c.

I might be missing something else as well, but those are the top things, IMO.

I hope this is helpful.

>  tools/lib/bpf/btf.c    |   10 +-
>  tools/lib/bpf/libbpf.c |  268 +++++++++++++++++++++++++++++++++++++++---------
>  tools/lib/bpf/libbpf.h |   17 +++
>  3 files changed, 244 insertions(+), 51 deletions(-)
>

[...]

Powered by blists - more mailing lists