[PATCH bpf-next 00/10] libbpf: support custom .rodata.*/.data.* sections

[andrii.nakryiko@gmail.com]

From: Andrii Nakryiko <andrii@kernel.org>

This patch set refactors internals of libbpf to enable support for multiple
custom .rodata.* and .data.* sections. Each such section is backed by its own
BPF_MAP_TYPE_ARRAY, memory-mappable just like .rodat/.data. This is not
extended to .bss because .bss is not a great name, it is generated by compiler
with name that reflects completely irrelevant historical implementation
details. Given that users have to annotate their variables with
SEC(".data.my_sec") explicitly, standardizing on .rodata. and .data. prefixes
makes more sense and keeps things simpler.

Additionally, this patch set makes it simpler to work with those special
internal maps by allowing to look them up by their full ELF section name.

Patch #1 is a preparatory patch that deprecated one libbpf API and moved
custom logic into libbpf.c where it's used. This code is later refactored with
the rest of libbpf.c logic to support multiple data section maps.

See individual patches for all the details.

One open question I have is whether we want to preserve this convoluted logic
of concatenating BPF object name with ELF section name for new custom data
sections/maps. Given their names are always going to be pretty long, it might
not make sense to drag this convention along and have kernel-side map name
differ from user-visible map name. See patch #7 for details on this.

One interesting possibility that is now open by these changes is that it's
possible to do:

    bpf_trace_printk("My fmt %s", sizeof("My fmt %s"), "blah");
    
and it will work as expected. I haven't updated libbpf-provided helpers in
bpf_helpers.h for snprintf, seq_printf, and printk, because using
`static const char ___fmt[] = fmt;` trick is still efficient and doesn't fill
out the buffer at runtime (no copying), but it also enforces that format
string is compile-time string literal:

    const char *s = NULL;

    bpf_printk("hi"); /* works */
    bpf_printk(s); /* compilation error */

By passing fmt directly to bpf_trace_printk() would actually compile
bpf_printk(s) above with no warnings and will not work at runtime, which is
worse user experience, IMO.

But there could be other interesting uses for non-trivial compile-time
constants nevertheless.

Andrii Nakryiko (10):
  libbpf: deprecate btf__finalize_data() and move it into libbpf.c
  libbpf: extract ELF processing state into separate struct
  libbpf: use Elf64-specific types explicitly for dealing with ELF
  libbpf: remove assumptions about uniqueness of .rodata/.data/.bss maps
  bpftool: support multiple .rodata/.data internal maps in skeleton
  bpftool: improve skeleton generation for data maps without DATASEC
    type
  libbpf: support multiple .rodata.* and .data.* BPF maps
  selftests/bpf: demonstrate use of custom .rodata/.data sections
  libbpf: simplify look up by name of internal maps
  selftests/bpf: switch to ".bss"/".rodata"/".data" lookups for internal
    maps

 tools/bpf/bpftool/gen.c                       | 158 ++--
 tools/lib/bpf/btf.c                           |  93 --
 tools/lib/bpf/btf.h                           |   1 +
 tools/lib/bpf/libbpf.c                        | 887 +++++++++++-------
 tools/lib/bpf/libbpf_internal.h               |   8 +-
 tools/lib/bpf/linker.c                        |   1 -
 .../selftests/bpf/prog_tests/core_autosize.c  |   2 +-
 .../selftests/bpf/prog_tests/core_reloc.c     |   2 +-
 .../selftests/bpf/prog_tests/global_data.c    |  11 +-
 .../bpf/prog_tests/global_data_init.c         |   2 +-
 .../selftests/bpf/prog_tests/kfree_skb.c      |   2 +-
 .../selftests/bpf/prog_tests/rdonly_maps.c    |   2 +-
 .../selftests/bpf/prog_tests/skeleton.c       |  25 +
 .../selftests/bpf/progs/test_skeleton.c       |  10 +
 14 files changed, 713 insertions(+), 491 deletions(-)

-- 
2.30.2