Em Tue, Oct 04, 2022 at 09:31:15AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Oct 04, 2022 at 09:17:47AM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Mon, Oct 03, 2022 at 10:56:36AM +0200, Martin Liška escreveu: > > > I noticed one can't build 5.19 with latest binutils master. > > > One see the following error: > > > [ 1413s] BTF .btf.vmlinux.bin.o > > > [ 1413s] Unsupported DW_TAG_unspecified_type(0x3b) > > > [ 1413s] Encountered error while encoding BTF. > > > > > > It's caused by DWARF coming from .S files and the change is introduced since > > > the following binutils revision: > > > > > > commit 5578fbf672ee497ea19826edeb509f4cc3e825a8 > > > Author: Nick Clifton <nickc@xxxxxxxxxx> > > > Date: Thu Aug 25 11:48:00 2022 +0100 > > > > > > GAS: Add a return type tag to DWARF DIEs generated for function symbols. > > > for entry.S the output changes to: > > > $ as-new --gdwarf-5 --64 -o entry.o entry.S && readelf -wi entry.o > > > Contents of the .debug_info section: > > > Compilation Unit @ offset 0x0: > > > Version: 5 > > > Unit Type: DW_UT_compile (1) > > > Abbrev Offset: 0x0 > > > <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG > > > <0><d>: Abbrev Number: 1 (DW_TAG_compile_unit) > > > <e> DW_AT_stmt_list : 0x0 > > > <12> DW_AT_low_pc : 0x0 > > > <1a> DW_AT_high_pc : 19 > > > <1b> DW_AT_name : (indirect string, offset: 0x0): ../arch/x86/entry/entry.S > > > <1f> DW_AT_comp_dir : (indirect string, offset: 0x1a): /tmp > > > <23> DW_AT_producer : (indirect string, offset: 0x1f): GNU AS 2.39.50 > > > <27> DW_AT_language : 32769 (MIPS assembler) > > > <1><29>: Abbrev Number: 2 (DW_TAG_subprogram) > > > <2a> DW_AT_name : (indirect string, offset: 0x2e): entry_ibpb > > > <2e> DW_AT_external : 1 > > > <2e> DW_AT_type : <0xc> > > Ok, it happens at the top level of a CU and there are users for it, now > > to try to figure out how to best support this in the pretty printer, > > DWARF loader and BTF encoder. > And it is for an assembly routine, which clarifies things a bit more, > Andrii, Yonghong, should we try to encode BTF for assembly? Or just > skip it? So, I added the one below to the next branch[1], unsure if the kernel verifier will choke on it. - Arnaldo [1] git://git.kernel.org/pub/scm/devel/pahole/pahole.git next This is a test branch, may or not go to master, CI uses it for testing once a day. >From 81519586f00836841538d3ca097588db6fc2c7a5 Mon Sep 17 00:00:00 2001 From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> Date: Tue, 4 Oct 2022 18:22:53 -0300 Subject: [PATCH 1/1] btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_UNKN This first appeared for assembler files in the Linux kernel with recent GNU compilers, we don't have anything in BTF, AFAIK, to properly represent that, so, for now, lets go with BTF_KIND_UNKN. Signed-off-by: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> --- btf_encoder.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/btf_encoder.c b/btf_encoder.c index 7ad3f29ef153d8d6..adc01396df6098d8 100644 --- a/btf_encoder.c +++ b/btf_encoder.c @@ -962,6 +962,8 @@ static int btf_encoder__encode_tag(struct btf_encoder *encoder, struct tag *tag, return btf_encoder__add_enum_type(encoder, tag, conf_load); case DW_TAG_subroutine_type: return btf_encoder__add_func_proto(encoder, tag__ftype(tag), type_id_off); + case DW_TAG_unspecified_type: + return btf_encoder__add_ref_type(encoder, BTF_KIND_UNKN, 0, NULL, false); default: fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n", dwarf_tag_name(tag->tag), tag->tag, ref_type_id); -- 2.37.3
