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

["Toke Høiland-Jørgensen" <toke@redhat.com>]

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