Re: [PATCH bpf-next v2] libbpf: ignore .eh_frame sections when parsing elf files

[Yonghong Song <yhs@fb.com>]

On 8/31/21 3:28 AM, Toke Høiland-Jørgensen wrote:
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> 
>> On Thu, Aug 26, 2021 at 5:10 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>>
>>> When .eh_frame and .rel.eh_frame sections are present in BPF object files,
>>> libbpf produces errors like this when loading the file:
>>>
>>> libbpf: elf: skipping unrecognized data section(32) .eh_frame
>>> libbpf: elf: skipping relo section(33) .rel.eh_frame for section(32) .eh_frame
>>>
>>> It is possible to get rid of the .eh_frame section by adding
>>> -fno-asynchronous-unwind-tables to the compilation, but we have seen
>>> multiple examples of these sections appearing in BPF files in the wild,
>>> most recently in samples/bpf, fixed by:
>>> 5a0ae9872d5c ("bpf, samples: Add -fno-asynchronous-unwind-tables to BPF Clang invocation")
>>>
>>> While the errors are technically harmless, they look odd and confuse users.
>>
>> These warnings point out invalid set of compiler flags used for
>> compiling BPF object files, though. Which is a good thing and should
>> incentivize anyone getting those warnings to check and fix how they do
>> BPF compilation. Those .eh_frame sections shouldn't be present in BPF
>> object files at all, and that's what libbpf is trying to say.
> 
> Apart from triggering that warning, what effect does this have, though?
> The programs seem to work just fine (as evidenced by the fact that
> samples/bpf has been built this way for years, for instance)...
> 
> Also, how is a user supposed to go from that cryptic error message to
> figuring out that it has something to do with compiler flags?
> 
>> I don't know exactly in which situations that .eh_frame section is
>> added, but looking at our selftests (and now samples/bpf as well),
>> where we use -target bpf, we don't need
>> -fno-asynchronous-unwind-tables at all.
> 
> This seems to at least be compiler-dependent. We ran into this with
> bpftool as well (for the internal BPF programs it loads whenever it
> runs), which already had '-target bpf' in the Makefile. We're carrying
> an internal RHEL patch adding -fno-asynchronous-unwind-tables to the
> bpftool build to fix this...

I haven't seen an instance of .eh_frame as well with -target bpf.
Do you have a reproducible test case? I would like to investigate
what is the possible cause and whether we could do something in llvm
to prevent its generatin. Thanks!

> 
>> So instead of hiding the problem, let's use this as an opportunity to
>> fix those user's compilation flags instead.
> 
> This really doesn't seem like something that's helping anyone, it's just
> annoying and confusing users...
> 
> -Toke
>