On Tue, Aug 31, 2021 at 3:28 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> 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?
Google and find discussions like these?.. I don't think libbpf error
messages have to include intro into DWARF and .eh_frame.
Just googling ".eh_frame" gives me [0] as a first link, which seems to
describe what it is and how to get rid of it.
[0] https://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section
>
> > 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...
So instead of figuring out why your compilers cause .eh_frame
generation (while they shouldn't), you are trying to hide the warning
in libbpf? This hasn't been the problem in production apps at
Facebook, nor with libbpf-tools or libbpf-bootstrap apps. Which just
makes me keep this warning more. Once we support multiple
.rodata/.data/.bss sections for libbpf, I think I'll turn all those
unrecognized sections into actual errors. I'd rather not have unknown
sections being just ignored by libbpf. Someday we might actually use
.eh_frame with BPF objects, that's when this will become not an error
or warning.
>
> > 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...
Warnings like "libbpf: elf: skipping unrecognized data section(4)
.rodata.str1.1" annoy me as well, and that's one of the reasons I'll
add support for multiple .rodata sections. So annoying is fine, it
raises awareness and incentivizes fixing the problem.
>
> -Toke
>
