Yonghong Song <yhs@xxxxxx> writes:
> On 8/31/21 3:28 AM, Toke Høiland-Jørgensen wrote:
>> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:
>>
>>> On Thu, Aug 26, 2021 at 5:10 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> 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!
We found this in the RHEL builds of bpftool. I don't think we're doing
anything special, other than maybe building with a clang version that's
a few versions behind:
# clang --version
clang version 11.0.0 (Red Hat 11.0.0-1.module+el8.4.0+8598+a071fcd5)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
So I suppose it may resolve itself once we upgrade LLVM?
-Toke
