Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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@redhat.com>
> > 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:
> >    Length:        0x35 (32-bit)
> >    Version:       5
> >    Unit Type:     DW_UT_compile (1)
> >    Abbrev Offset: 0x0
> >    Pointer Size:  8
> >  <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?

Martin, can you try a facility that was put in place to skip Rust kernel
modules, for some other DWARF generation problem?

oops, I didn't antecipate, assembler, so please try with the patch below
and then add:

   --lang_exclude asm

I.e. this extra patch, for the kernel:

diff --git a/scripts/pahole-flags.sh b/scripts/pahole-flags.sh
index 0d99ef17e4a52876..b999c6f0979ac02c 100755
--- a/scripts/pahole-flags.sh
+++ b/scripts/pahole-flags.sh
@@ -20,4 +20,8 @@ if [ "${pahole_ver}" -ge "122" ]; then
 	extra_paholeopt="${extra_paholeopt} -j"
 fi
 
+if [ "${pahole_ver}" -ge "124" ]; then
+	extra_paholeopt="${extra_paholeopt} --lang_exclude asm"
+fi
+
 echo ${extra_paholeopt}


------------------------------------------------------------------------

diff --git a/dwarves.c b/dwarves.c
index 9589747f49f8f3a7..0405592ce0a540a5 100644
--- a/dwarves.c
+++ b/dwarves.c
@@ -2240,6 +2240,9 @@ int lang__str2int(const char *lang)
 	[DW_LANG_UPC]		 = "upc",
 	};
 
+	if (strcasecmp(lang, "asm") == 0)
+		return DW_LANG_Mips_Assembler;
+
 	// c89 is the first, bliss is the last, see /usr/include/dwarf.h
 	for (int id = DW_LANG_C89; id <= DW_LANG_BLISS; ++id)
 		if (languages[id] && strcasecmp(lang, languages[id]) == 0)