bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Reason for libbpf rejecting SECTION symbols in 'maps' section
@ 2021-09-24 16:49 Toke Høiland-Jørgensen
  2021-09-24 23:52 ` Andrii Nakryiko
  0 siblings, 1 reply; 3+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-09-24 16:49 UTC (permalink / raw)
  To: Andrii Nakryiko; +Cc: bpf, Jiri Benc

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Reason for libbpf rejecting SECTION symbols in 'maps' section
  2021-09-24 16:49 Reason for libbpf rejecting SECTION symbols in 'maps' section Toke Høiland-Jørgensen
@ 2021-09-24 23:52 ` Andrii Nakryiko
  2021-09-25  9:19   ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 3+ messages in thread
From: Andrii Nakryiko @ 2021-09-24 23:52 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen; +Cc: bpf, Jiri Benc

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Reason for libbpf rejecting SECTION symbols in 'maps' section
  2021-09-24 23:52 ` Andrii Nakryiko
@ 2021-09-25  9:19   ` Toke Høiland-Jørgensen
  0 siblings, 0 replies; 3+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-09-25  9:19 UTC (permalink / raw)
  To: Andrii Nakryiko; +Cc: bpf, Jiri Benc

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-09-25  9:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-24 16:49 Reason for libbpf rejecting SECTION symbols in 'maps' section Toke Høiland-Jørgensen
2021-09-24 23:52 ` Andrii Nakryiko
2021-09-25  9:19   ` Toke Høiland-Jørgensen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).