Re: Reason for libbpf rejecting SECTION symbols in 'maps' section

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Fri, Sep 24, 2021 at 9:49 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Hi Andrii
>
> We ran into an issue with binutils[0] mangling BPF object files, which
> makes libbpf sad. Specifically, binutils will create SECTION symbols for
> every section in .symtab, which trips this check in
> bpf_object__init_user_maps():
>
> if (GELF_ST_TYPE(sym.st_info) == STT_SECTION
>     || GELF_ST_BIND(sym.st_info) == STB_LOCAL) {
>         pr_warn("map '%s' (legacy): static maps are not supported\n", map_name);
>         return -ENOTSUP;
> }
>
> Given the error message I can understand why it's checking for
> STB_LOCAL, but why is the check for STT_SECTION there? And is there any
> reason why libbpf couldn't just skip the SECTION symbols instead of
> bugging out?

Static functions are often referenced through STT_SECTION symbol +
some offset. I don't remember by now if I encountered cases where
static variables can be referenced through section symbol + offset, I
suspect I did, which is why I added this check.

But thinking about this now, we should just ignore the STT_SECTION
symbol. If Clang really referenced map through STT_SECTION symbol,
we'll later won't find a corresponding bpf_map instance for a
corresponding relocation.

So I think it's fine to drop the STT_SECTION.

>
> Hope you can help shed some light on the history here.
>
> -Toke
>
>
> [0] This happens because rpmbuild has a script that automatically that
> runs 'strip' on every object file in an rpm; and so when we package up
> the kernel selftests, we end up with mangled object files. Newer
> versions of binutils don't do this, but the one on RHEL does.
>