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@xxxxxxxxxx>
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?
--- tools/lib/bpf/libbpf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 1e04ce724240..676af6be5961 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -2906,7 +2906,8 @@ static Elf_Data *elf_sec_data(const struct bpf_object *obj, Elf_Scn *scn) static bool is_sec_name_dwarf(const char *name) { /* approximation, but the actual list is too long */ - return strncmp(name, ".debug_", sizeof(".debug_") - 1) == 0; + return (strncmp(name, ".debug_", sizeof(".debug_") - 1) == 0 || + strncmp(name, ".eh_frame", sizeof(".eh_frame") - 1) == 0); }static bool ignore_elf_section(GElf_Shdr *hdr, const char *name)
Thanks, Daniel
