Reason for libbpf rejecting SECTION symbols in 'maps' section

Reason for libbpf rejecting SECTION symbols in 'maps' section

[Toke Høiland-Jørgensen]

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?

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.

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

[Andrii Nakryiko]

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.
>

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

[Toke Høiland-Jørgensen]

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

> 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.

Great, thanks! I'll send a patch :)

-Toke