All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next] libbpf: ignore .eh_frame sections when parsing elf files
Date: Mon, 05 Jul 2021 12:33:09 +0200	[thread overview]
Message-ID: <87czrxyrru.fsf@toke.dk> (raw)
In-Reply-To: <ac14ef3c-ccd5-5f74-dda5-1d9366883813@iogearbox.net>

Daniel Borkmann <daniel@iogearbox.net> writes:

> On 6/29/21 1:09 PM, Toke Høiland-Jørgensen wrote:
>> The .eh_frame and .rel.eh_frame sections will be present in BPF object
>> files when compiled using a multi-stage compile pipe like in samples/bpf.
>> This produces errors when loading such a file with libbpf. While the errors
>> are technically harmless, they look odd and confuse users. So add .eh_frame
>> sections to is_sec_name_dwarf() so they will also be ignored by libbpf
>> processing. This gets rid of output like this from samples/bpf:
>> 
>> libbpf: elf: skipping unrecognized data section(32) .eh_frame
>> libbpf: elf: skipping relo section(33) .rel.eh_frame for section(32) .eh_frame
>> 
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> For the samples/bpf case, could we instead just add a -fno-asynchronous-unwind-tables
> to clang as cflags to avoid .eh_frame generation in the first place?

Ah, great suggestion! Was trying, but failed, to figure out how to do
that. Just tested it, and yeah, that does fix samples; will send a
separate patch to add that.

I still think filtering this section name in libbpf is worthwhile,
though, as the error message is really just noise... WDYT?

-Toke


  reply	other threads:[~2021-07-05 10:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 11:09 [PATCH bpf-next] libbpf: ignore .eh_frame sections when parsing elf files Toke Høiland-Jørgensen
2021-07-02 16:10 ` Daniel Borkmann
2021-07-05 10:33   ` Toke Høiland-Jørgensen [this message]
2021-07-05 20:41     ` Daniel Borkmann
2021-07-06 11:51       ` Toke Høiland-Jørgensen
2021-07-06 16:10         ` Yonghong Song
2021-07-06 22:31           ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czrxyrru.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.