* Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
@ 2022-10-03 8:56 Martin Liška
2022-10-03 12:07 ` Nick Clifton
` (3 more replies)
0 siblings, 4 replies; 33+ messages in thread
From: Martin Liška @ 2022-10-03 8:56 UTC (permalink / raw)
To: dwarves; +Cc: Arnaldo Carvalho de Melo, Nick Clifton
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>
<2f> DW_AT_low_pc : 0x0
<37> DW_AT_high_pc : 19
<1><38>: Abbrev Number: 0
Is it something pahole should handle?
Thanks,
Martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-03 8:56 Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b) Martin Liška
@ 2022-10-03 12:07 ` Nick Clifton
2022-10-04 12:15 ` Arnaldo Carvalho de Melo
2022-10-04 12:17 ` Arnaldo Carvalho de Melo
` (2 subsequent siblings)
3 siblings, 1 reply; 33+ messages in thread
From: Nick Clifton @ 2022-10-03 12:07 UTC (permalink / raw)
To: Martin Liška, dwarves; +Cc: Arnaldo Carvalho de Melo
Hi Martin,
> 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)
> <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
> Is it something pahole should handle?
Yes, I believe so. The tag is a valid DWARF tag, and GDB wants it, so
it would be good if pahole could support it.
Cheers
Nick
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-03 12:07 ` Nick Clifton
@ 2022-10-04 12:15 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 12:15 UTC (permalink / raw)
To: Nick Clifton; +Cc: Martin Liška, dwarves
Em Mon, Oct 03, 2022 at 01:07:14PM +0100, Nick Clifton escreveu:
> Hi Martin,
>
> > 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)
>
> > <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
>
> > Is it something pahole should handle?
>
> Yes, I believe so. The tag is a valid DWARF tag, and GDB wants it, so
> it would be good if pahole could support it.
I'll check and fix this, thanks for the report.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-03 8:56 Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b) Martin Liška
2022-10-03 12:07 ` Nick Clifton
@ 2022-10-04 12:17 ` Arnaldo Carvalho de Melo
2022-10-04 12:31 ` Arnaldo Carvalho de Melo
2022-10-04 12:33 ` Nick Clifton
2022-10-04 21:44 ` Arnaldo Carvalho de Melo
2022-10-05 16:55 ` Arnaldo Carvalho de Melo
3 siblings, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 12:17 UTC (permalink / raw)
To: Martin Liška, Yonghong Song, Andrii Nakryiko; +Cc: dwarves, Nick Clifton
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.
- Arnaldo
> <2f> DW_AT_low_pc : 0x0
> <37> DW_AT_high_pc : 19
> <1><38>: Abbrev Number: 0
>
> Is it something pahole should handle?
>
> Thanks,
> Martin
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 12:17 ` Arnaldo Carvalho de Melo
@ 2022-10-04 12:31 ` Arnaldo Carvalho de Melo
2022-10-04 21:42 ` Arnaldo Carvalho de Melo
2022-10-05 8:41 ` Martin Liška
2022-10-04 12:33 ` Nick Clifton
1 sibling, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 12:31 UTC (permalink / raw)
To: Martin Liška, Yonghong Song, Andrii Nakryiko; +Cc: dwarves, Nick Clifton
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)
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 12:17 ` Arnaldo Carvalho de Melo
2022-10-04 12:31 ` Arnaldo Carvalho de Melo
@ 2022-10-04 12:33 ` Nick Clifton
2022-10-04 13:25 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 33+ messages in thread
From: Nick Clifton @ 2022-10-04 12:33 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Martin Liška, Yonghong Song,
Andrii Nakryiko
Cc: dwarves
Hi Arnaldo,
>> <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
>> <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
>> <2a> DW_AT_name : (indirect string, offset: 0x2e): entry_ibpb
>> <2e> DW_AT_type : <0xc>
If it helps the tag is used to tell consumers like GDB that the return
type of specific functions (eg entry_ibpb in the above example) is unknown.
Cheers
Nick
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 12:33 ` Nick Clifton
@ 2022-10-04 13:25 ` Arnaldo Carvalho de Melo
2022-10-04 18:07 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 13:25 UTC (permalink / raw)
To: Nick Clifton, Arnaldo Carvalho de Melo, Martin Liška,
Yonghong Song, Andrii Nakryiko
Cc: dwarves
On October 4, 2022 9:33:05 AM GMT-03:00, Nick Clifton <nickc@redhat.com> wrote:
>Hi Arnaldo,
>
>>> <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
>
>>> <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
>>> <2a> DW_AT_name : (indirect string, offset: 0x2e): entry_ibpb
>>> <2e> DW_AT_type : <0xc>
>
>If it helps the tag is used to tell consumers like GDB that the return
>type of specific functions (eg entry_ibpb in the above example) is unknown.
Sure helps, thanks!
I noticed this is for assembly source code, I'll add it as a special "type" and probably for BTF mask it to void.
- Arnaldo
>
>Cheers
> Nick
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 13:25 ` Arnaldo Carvalho de Melo
@ 2022-10-04 18:07 ` Arnaldo Carvalho de Melo
2022-10-04 21:13 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 18:07 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Nick Clifton, Martin Liška, Yonghong Song, Andrii Nakryiko, dwarves
Em Tue, Oct 04, 2022 at 10:25:31AM -0300, Arnaldo Carvalho de Melo escreveu:
> On October 4, 2022 9:33:05 AM GMT-03:00, Nick Clifton <nickc@redhat.com> wrote:
> >Hi Arnaldo,
> >
> >>> <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
> >
> >>> <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
> >>> <2a> DW_AT_name : (indirect string, offset: 0x2e): entry_ibpb
> >>> <2e> DW_AT_type : <0xc>
> >
> >If it helps the tag is used to tell consumers like GDB that the return
> >type of specific functions (eg entry_ibpb in the above example) is unknown.
> Sure helps, thanks!
> I noticed this is for assembly source code, I'll add it as a special
> "type" and probably for BTF mask it to void.
s/mask/map/g
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 18:07 ` Arnaldo Carvalho de Melo
@ 2022-10-04 21:13 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 21:13 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Nick Clifton, Martin Liška, Yonghong Song, Andrii Nakryiko, dwarves
Em Tue, Oct 04, 2022 at 03:07:57PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Oct 04, 2022 at 10:25:31AM -0300, Arnaldo Carvalho de Melo escreveu:
> > On October 4, 2022 9:33:05 AM GMT-03:00, Nick Clifton <nickc@redhat.com> wrote:
> > >Hi Arnaldo,
> > >
> > >>> <0><c>: Abbrev Number: 3 (DW_TAG_unspecified_type) <--- the problematic TAG
> > >
> > >>> <1><29>: Abbrev Number: 2 (DW_TAG_subprogram)
> > >>> <2a> DW_AT_name : (indirect string, offset: 0x2e): entry_ibpb
> > >>> <2e> DW_AT_type : <0xc>
> > >
> > >If it helps the tag is used to tell consumers like GDB that the return
> > >type of specific functions (eg entry_ibpb in the above example) is unknown.
>
> > Sure helps, thanks!
>
> > I noticed this is for assembly source code, I'll add it as a special
> > "type" and probably for BTF mask it to void.
>
> s/mask/map/g
I just committed the patch below, now to support
DW_TAG_unspecified_type...
- Arnaldo
commit 79d9a783ea74797aa4304009e0cf1bdb9235fcf4
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Tue Oct 4 18:09:33 2022 -0300
pahole: Support '--lang/--lang_exclude=asm'
It is disjoint from the other languages and then the first simple
implementation of language inclusion/exclusion didn't support it, add
an special case to test against 0x8001 (DW_LANG_Mips_Assembler) to cover
that.
This is needed as recently compilers started to add DWARF constructs to
represent asm CUs that broke pahole as it didn't support
DW_TAG_unspecified_type as a "type", so add it in case in the future we
want to exclude such CUs.
The DW_TAG_unspecified_type tag is going to be supported in the next
csets tho.
We also may want this to exclude new tags that aren't supported in BTF,
etc.
Cc: Martin Liška <mliska@suse.cz>
Cc: Nick Clifton <nickc@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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)
diff --git a/man-pages/pahole.1 b/man-pages/pahole.1
index d752ccbeb297d9d7..45a21af500d94772 100644
--- a/man-pages/pahole.1
+++ b/man-pages/pahole.1
@@ -378,7 +378,7 @@ Only process compilation units built from source code written in the specified l
Supported languages:
- ada83, ada95, bliss, c, c89, c99, c11, c++, c++03, c++11, c++14, cobol74,
+ ada83, ada95, asm, bliss, c, c89, c99, c11, c++, c++03, c++11, c++14, cobol74,
cobol85, d, dylan, fortran77, fortran90, fortran95, fortran03, fortran08,
go, haskell, java, julia, modula2, modula3, objc, objc++, ocaml, opencl,
pascal83, pli, python, renderscript, rust, swift, upc
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 12:31 ` Arnaldo Carvalho de Melo
@ 2022-10-04 21:42 ` Arnaldo Carvalho de Melo
2022-10-05 8:41 ` Martin Liška
1 sibling, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 21:42 UTC (permalink / raw)
To: Martin Liška, Yonghong Song, Andrii Nakryiko; +Cc: dwarves, Nick Clifton
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@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:
> > > 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@redhat.com>
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@redhat.com>
---
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
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-03 8:56 Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b) Martin Liška
2022-10-03 12:07 ` Nick Clifton
2022-10-04 12:17 ` Arnaldo Carvalho de Melo
@ 2022-10-04 21:44 ` Arnaldo Carvalho de Melo
2022-10-05 7:23 ` Martin Liška
2022-10-05 16:55 ` Arnaldo Carvalho de Melo
3 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-04 21:44 UTC (permalink / raw)
To: Martin Liška; +Cc: dwarves, Nick Clifton
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.
I assume "binutils master" means:
git://sourceware.org/git/binutils-gdb.git master?
- Arnaldo
> 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>
> <2f> DW_AT_low_pc : 0x0
> <37> DW_AT_high_pc : 19
> <1><38>: Abbrev Number: 0
>
> Is it something pahole should handle?
>
> Thanks,
> Martin
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 21:44 ` Arnaldo Carvalho de Melo
@ 2022-10-05 7:23 ` Martin Liška
2022-10-05 14:37 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Martin Liška @ 2022-10-05 7:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: dwarves, Nick Clifton
On 10/4/22 23:44, Arnaldo Carvalho de Melo wrote:
> I assume "binutils master" means:
>
> git://sourceware.org/git/binutils-gdb.git master?
Yes.
Martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-04 12:31 ` Arnaldo Carvalho de Melo
2022-10-04 21:42 ` Arnaldo Carvalho de Melo
@ 2022-10-05 8:41 ` Martin Liška
1 sibling, 0 replies; 33+ messages in thread
From: Martin Liška @ 2022-10-05 8:41 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Yonghong Song, Andrii Nakryiko
Cc: dwarves, Nick Clifton
On 10/4/22 14:31, Arnaldo Carvalho de Melo wrote:
> |Martin, can you try a facility that was put in place to skip Rust kernel modules, for some other DWARF generation problem?|
Hi.
Can't test that right now as we miss latest libbpf and dwarves in openSUSE Tumbleweed. Apparently,
we're waiting for systemd support ([1]).
So it might be easier for you to reproduce the issue with latest binutils, right?
Cheers,
Martin
[1] https://github.com/systemd/systemd/issues/24464
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-05 7:23 ` Martin Liška
@ 2022-10-05 14:37 ` Arnaldo Carvalho de Melo
2022-10-05 15:43 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-05 14:37 UTC (permalink / raw)
To: Martin Liška; +Cc: dwarves, Nick Clifton
Em Wed, Oct 05, 2022 at 09:23:32AM +0200, Martin Liška escreveu:
> On 10/4/22 23:44, Arnaldo Carvalho de Melo wrote:
> > I assume "binutils master" means:
> >
> > git://sourceware.org/git/binutils-gdb.git master?
>
> Yes.
Taking notes:
Using what is in opensuse:tumbleweed it works:
15e20ce2324a:~/git/linux # ls -la ../build/v6.0.0+/vmlinux
-rwxr-xr-x. 1 root root 674990096 Oct 5 14:30 ../build/v6.0.0+/vmlinux
15e20ce2324a:~/git/linux # pahole ../build/v6.0.0+/vmlinux > /dev/null
15e20ce2324a:~/git/linux # time pahole ../build/v6.0.0+/vmlinux > /dev/null
real 0m5.155s
user 0m4.518s
sys 0m0.608s
15e20ce2324a:~/git/linux # time pahole -F dwarf ../build/v6.0.0+/vmlinux > /dev/null
real 0m5.184s
user 0m4.504s
sys 0m0.662s
15e20ce2324a:~/git/linux # time pahole -F btf ../build/v6.0.0+/vmlinux > /dev/null
real 0m0.077s
user 0m0.057s
sys 0m0.020s
15e20ce2324a:~/git/linux # btfdiff ../build/v6.0.0+/vmlinux
15e20ce2324a:~/git/linux # pahole -F btf -C spinlock_t ../build/v6.0.0+/vmlinux > /dev/null
15e20ce2324a:~/git/linux # pahole -F btf -C spinlock_t ../build/v6.0.0+/vmlinux
typedef struct spinlock spinlock_t;
15e20ce2324a:~/git/linux # pahole -EF btf -C spinlock_t ../build/v6.0.0+/vmlinux
typedef struct spinlock spinlock_t;
15e20ce2324a:~/git/linux # pahole -F btf -C spinlock ../build/v6.0.0+/vmlinux
struct spinlock {
union {
struct raw_spinlock rlock; /* 0 4 */
}; /* 0 4 */
/* size: 4, cachelines: 1, members: 1 */
/* last cacheline: 4 bytes */
};
15e20ce2324a:~/git/linux # pahole -EF btf -C spinlock ../build/v6.0.0+/vmlinux
struct spinlock {
union {
struct raw_spinlock {
/* typedef arch_spinlock_t */ struct qspinlock {
union {
/* typedef atomic_t */ struct {
int counter; /* 0 4 */
} val; /* 0 4 */
struct {
/* typedef u8 -> __u8 */ unsigned char locked; /* 0 1 */
/* typedef u8 -> __u8 */ unsigned char pending; /* 1 1 */
}; /* 0 2 */
struct {
/* typedef u16 -> __u16 */ short unsigned int locked_pending; /* 0 2 */
/* typedef u16 -> __u16 */ short unsigned int tail; /* 2 2 */
}; /* 0 4 */
}; /* 0 4 */
} raw_lock; /* 0 4 */
} rlock; /* 0 4 */
}; /* 0 4 */
/* size: 4, cachelines: 1, members: 1 */
/* last cacheline: 4 bytes */
};
15e20ce2324a:~/git/linux # pahole --version
v1.22
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # rpm -q binutils
binutils-2.38-6.2.x86_64
15e20ce2324a:~/git/linux #
Now to update binutils.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-05 14:37 ` Arnaldo Carvalho de Melo
@ 2022-10-05 15:43 ` Arnaldo Carvalho de Melo
2022-10-06 11:54 ` Martin Liška
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-05 15:43 UTC (permalink / raw)
To: Martin Liška; +Cc: dwarves, Nick Clifton
Em Wed, Oct 05, 2022 at 11:37:13AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Oct 05, 2022 at 09:23:32AM +0200, Martin Liška escreveu:
> > On 10/4/22 23:44, Arnaldo Carvalho de Melo wrote:
> > > I assume "binutils master" means:
> > >
> > > git://sourceware.org/git/binutils-gdb.git master?
> >
> > Yes.
>
> Taking notes:
>
> Using what is in opensuse:tumbleweed it works:
So I built and installed from git://sourceware.org/git/binutils-gdb.git,
it got on /usr/local/bin, taking precedence above /usr/bin/, and didn't
get any DW_TAG_unspecified_type:
15e20ce2324a:~/git/linux # type readelf
readelf is hashed (/usr/local/bin/readelf)
15e20ce2324a:~/git/linux # /usr/local/bin/readelf -v
GNU readelf (GNU Binutils) 2.39.50.20221005
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
15e20ce2324a:~/git/linux # rpm -q binutils
binutils-2.38-6.2.x86_64
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # readelf -wi ../build/v6.0.0+binutils-latest/vmlinux|grep DW_TAG_unspecified_type
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # egrep BTF\|DWARF\|PAHOLE ../build/v6.0.0+binutils-latest/.config
CONFIG_PAHOLE_VERSION=122
CONFIG_VIDEO_SONY_BTF_MPX=m
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_DEBUG_INFO_DWARF5 is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_PAHOLE_HAS_SPLIT_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
# CONFIG_MODULE_ALLOW_BTF_MISMATCH is not set
15e20ce2324a:~/git/linux #
Its CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y and it ends up being
DWARF5 as its the toolchain default, at least from the
/usr/local/bin/readelf -wi output below.
Can you hand me your kernel .config file, please?
<1><92163>: Abbrev Number: 0
Compilation Unit @ offset 0x92164:
Length: 0x24 (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0x5555
Pointer Size: 8
<0><92170>: Abbrev Number: 1 (DW_TAG_compile_unit)
<92171> DW_AT_stmt_list : 0x7df2
<92175> DW_AT_low_pc : 0xffffffff81c62000
<9217d> DW_AT_high_pc : 19
<9217e> DW_AT_name : (indirect string, offset: 0x1878d): /root/git/linux/arch/x86/entry/entry.S
<92182> DW_AT_comp_dir : (indirect string, offset: 0x2a): /root/git/build/v6.0.0+binutils-latest
<92186> DW_AT_producer : (indirect string, offset: 0x51): GNU AS 2.38
<9218a> DW_AT_language : 32769 (MIPS assembler)
Compilation Unit @ offset 0x9218c:
Length: 0x1f (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0x5569
Pointer Size: 8
<0><92198>: Abbrev Number: 1 (DW_TAG_compile_unit)
<92199> DW_AT_stmt_list : 0x7e43
<9219d> DW_AT_ranges : 0x12e3
<921a1> DW_AT_name : (indirect string, offset: 0x187b4): /root/git/linux/arch/x86/entry/entry_64.S
<921a5> DW_AT_comp_dir : (indirect string, offset: 0x2a): /root/git/build/v6.0.0+binutils-latest
<921a9> DW_AT_producer : (indirect string, offset: 0x51): GNU AS 2.38
<921ad> DW_AT_language : 32769 (MIPS assembler)
Compilation Unit @ offset 0x921af:
Length: 0x1e93 (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0x557b
Pointer Size: 8
<0><921bb>: Abbrev Number: 13 (DW_TAG_compile_unit)
<921bc> DW_AT_producer : (indirect string, offset: 0x6622): GNU C11 12.1.1 20220629 [revision 7811663964aa7e31c3939b859bbfa2e16919639f] -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -mharden-sls=all -mrecord-mcount -mfentry -march=x86-64 -g -O2 -std=gnu11 -p -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -fcf-protection=none -falign-jumps=1 -falign-loops=1 -fno-asynchronous-unwind-tables -fno-jump-tables -fno-delete-null-pointer-checks -fno-allow-store-data-races -fstack-protector-strong -fno-stack-clash-protection -fzero-call-used-regs=used-gpr -fno-strict-overflow -fstack-check=no -fconserve-stack
<921c0> DW_AT_language : 29 (C11)
<921c1> DW_AT_name : (indirect line string, offset: 0x14b6): /root/git/linux/arch/x86/entry/syscall_64.c
<921c5> DW_AT_comp_dir : (indirect line string, offset: 0): /root/git/build/v6.0.0+binutils-latest
<921c9> DW_AT_stmt_list : 0x8110
<1><921cd>: Abbrev Number: 6 (DW_TAG_base_type)
<921ce> DW_AT_byte_size : 8
<921cf> DW_AT_encoding : 7 (unsigned)
<921d0> DW_AT_name : (indirect string, offset: 0x4dc4): long unsigned int
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-03 8:56 Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b) Martin Liška
` (2 preceding siblings ...)
2022-10-04 21:44 ` Arnaldo Carvalho de Melo
@ 2022-10-05 16:55 ` Arnaldo Carvalho de Melo
3 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-05 16:55 UTC (permalink / raw)
To: Martin Liška; +Cc: dwarves, Nick Clifton
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>
> <2f> DW_AT_low_pc : 0x0
> <37> DW_AT_high_pc : 19
> <1><38>: Abbrev Number: 0
>
> Is it something pahole should handle?
So if I build with clang 14 on opensuse tumbleweed I end up with:
<2><5c234>: Abbrev Number: 0
<1><5c235>: Abbrev Number: 0
Compilation Unit @ offset 0x5c236:
Length: 0x9f (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0x355b
Pointer Size: 8
<0><5c242>: Abbrev Number: 1 (DW_TAG_compile_unit)
<5c243> DW_AT_stmt_list : 0xa3b8
<5c247> DW_AT_low_pc : 0xffffffff81c22000
<5c24f> DW_AT_high_pc : 0xffffffff81c2200f
<5c257> DW_AT_name : /root/git/linux/arch/x86/entry/entry.S
<5c27e> DW_AT_comp_dir : /root/git/build/v6.0.0+binutils-latest
<5c2a5> DW_AT_producer : clang version 14.0.6
<5c2ba> DW_AT_language : 32769 (MIPS assembler)
<1><5c2bc>: Abbrev Number: 2 (DW_TAG_label)
<5c2bd> DW_AT_name : entry_ibpb
<5c2c8> DW_AT_decl_file : 0
<5c2cc> DW_AT_decl_line : 0x95
<5c2d0> DW_AT_low_pc : 0xffffffff81c22000
<1><5c2d8>: Abbrev Number: 0
clang uses DW_TAG_label for entry_ibpb, while GNU AS 2.39.50 generates
DW_TAG_subprogram.
But then the one I'm using when building with gcc, same
opensuse:tumbleweed container:
15e20ce2324a:~/git/linux # as --version
GNU assembler (GNU Binutils) 2.39.50.20221005
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.
15e20ce2324a:~/git/linux #
Isn't producing anything for entry_ibpb :-\
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-05 15:43 ` Arnaldo Carvalho de Melo
@ 2022-10-06 11:54 ` Martin Liška
[not found] ` <Yz7bevBJAm0JiLfp@kernel.org>
0 siblings, 1 reply; 33+ messages in thread
From: Martin Liška @ 2022-10-06 11:54 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: dwarves, Nick Clifton
On 10/5/22 17:43, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 05, 2022 at 11:37:13AM -0300, Arnaldo Carvalho de Melo
> escreveu:
>> Em Wed, Oct 05, 2022 at 09:23:32AM +0200, Martin Liška escreveu:
>>> On 10/4/22 23:44, Arnaldo Carvalho de Melo wrote:
>>>> I assume "binutils master" means:
>>>>
>>>> git://sourceware.org/git/binutils-gdb.git master?
>>>
>>> Yes.
>>
>> Taking notes:
>>
>> Using what is in opensuse:tumbleweed it works:
>
> So I built and installed from
> git://sourceware.org/git/binutils-gdb.git, it got on /usr/local/bin,
> taking precedence above /usr/bin/, and didn't get any
> DW_TAG_unspecified_type:
Hey.
Well, it's more trickier what gcc driver runs as a GAS even though you prefixed
/usr/local/bin.
$ echo '' | gcc -c -x c - --verbose 2>&1 | grep 'as\>'
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/as -v --64 -o -.o /tmp/cclvchQd.s
Anyway, the easiest approach how to use a different gas is using -B gcc option, which
would search the location for 'as' binary:
$ pwd
/home/marxin/Programming/binutils/objdir/gas
$ ./as-new --version
GNU assembler (GNU Binutils) 2.39.50.20221004
...
$ ln -s as-new as
$ gcc -Wp,-MMD,arch/x86/entry/.entry.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -c -o arch/x86/entry/entry.o arch/x86/entry/entry.S -g -B/home/marxin/Programming/binutils/objdir/gas
(note I'm using make defconfig), and not I can see:
$ readelf -wi arch/x86/entry/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: 1 (DW_TAG_compile_unit)
<d> DW_AT_stmt_list : 0x0
<11> DW_AT_low_pc : 0x0
<19> DW_AT_high_pc : 19
<1a> DW_AT_name : (indirect string, offset: 0x0): arch/x86/entry/entry.S
<1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /home/marxin/Programming/linux
<22> DW_AT_producer : (indirect string, offset: 0x36): GNU AS 2.39.50
<26> DW_AT_language : 32769 (MIPS assembler)
<1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
<29> DW_AT_name : (indirect string, offset: 0x45): entry_ibpb
<2d> DW_AT_external : 1
<2d> DW_AT_type : <0x37>
<2e> DW_AT_low_pc : 0x0
<36> DW_AT_high_pc : 19
<1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
<1><38>: Abbrev Number: 0
as seen, you get the DW_AT_producer tag that shows the AS version (2.39.50)
and the DW_TAG_unspecified_type tag.
Cheers,
Martin
>
> 15e20ce2324a:~/git/linux # type readelf readelf is hashed
> (/usr/local/bin/readelf) 15e20ce2324a:~/git/linux #
> /usr/local/bin/readelf -v GNU readelf (GNU Binutils)
> 2.39.50.20221005 Copyright (C) 2022 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the
> terms of the GNU General Public License version 3 or (at your option)
> any later version. This program has absolutely no warranty.
> 15e20ce2324a:~/git/linux # rpm -q binutils binutils-2.38-6.2.x86_64
> 15e20ce2324a:~/git/linux #
>
> 15e20ce2324a:~/git/linux # readelf -wi
> ../build/v6.0.0+binutils-latest/vmlinux|grep DW_TAG_unspecified_type
> 15e20ce2324a:~/git/linux #
>
> 15e20ce2324a:~/git/linux # egrep BTF\|DWARF\|PAHOLE
> ../build/v6.0.0+binutils-latest/.config CONFIG_PAHOLE_VERSION=122
> CONFIG_VIDEO_SONY_BTF_MPX=m
> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y #
> CONFIG_DEBUG_INFO_DWARF4 is not set # CONFIG_DEBUG_INFO_DWARF5 is not
> set CONFIG_DEBUG_INFO_BTF=y CONFIG_PAHOLE_HAS_SPLIT_BTF=y
> CONFIG_DEBUG_INFO_BTF_MODULES=y # CONFIG_MODULE_ALLOW_BTF_MISMATCH is
> not set 15e20ce2324a:~/git/linux #
>
>
> Its CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y and it ends up being
> DWARF5 as its the toolchain default, at least from the
> /usr/local/bin/readelf -wi output below.
>
> Can you hand me your kernel .config file, please?
>
>
> <1><92163>: Abbrev Number: 0 Compilation Unit @ offset 0x92164:
> Length: 0x24 (32-bit) Version: 5 Unit Type:
> DW_UT_compile (1) Abbrev Offset: 0x5555 Pointer Size: 8 <0><92170>:
> Abbrev Number: 1 (DW_TAG_compile_unit) <92171> DW_AT_stmt_list :
> 0x7df2 <92175> DW_AT_low_pc : 0xffffffff81c62000 <9217d>
> DW_AT_high_pc : 19 <9217e> DW_AT_name : (indirect
> string, offset: 0x1878d): /root/git/linux/arch/x86/entry/entry.S
> <92182> DW_AT_comp_dir : (indirect string, offset: 0x2a):
> /root/git/build/v6.0.0+binutils-latest <92186> DW_AT_producer :
> (indirect string, offset: 0x51): GNU AS 2.38 <9218a> DW_AT_language
> : 32769 (MIPS assembler) Compilation Unit @ offset 0x9218c: Length:
> 0x1f (32-bit) Version: 5 Unit Type: DW_UT_compile (1)
> Abbrev Offset: 0x5569 Pointer Size: 8 <0><92198>: Abbrev Number: 1
> (DW_TAG_compile_unit) <92199> DW_AT_stmt_list : 0x7e43 <9219d>
> DW_AT_ranges : 0x12e3 <921a1> DW_AT_name : (indirect
> string, offset: 0x187b4): /root/git/linux/arch/x86/entry/entry_64.S
> <921a5> DW_AT_comp_dir : (indirect string, offset: 0x2a):
> /root/git/build/v6.0.0+binutils-latest <921a9> DW_AT_producer :
> (indirect string, offset: 0x51): GNU AS 2.38 <921ad> DW_AT_language
> : 32769 (MIPS assembler) Compilation Unit @ offset 0x921af: Length:
> 0x1e93 (32-bit) Version: 5 Unit Type: DW_UT_compile (1)
> Abbrev Offset: 0x557b Pointer Size: 8 <0><921bb>: Abbrev Number: 13
> (DW_TAG_compile_unit) <921bc> DW_AT_producer : (indirect string,
> offset: 0x6622): GNU C11 12.1.1 20220629 [revision
> 7811663964aa7e31c3939b859bbfa2e16919639f] -mno-sse -mno-mmx -mno-sse2
> -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387
> -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
> -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern
> -mindirect-branch-register -mindirect-branch-cs-prefix
> -mfunction-return=thunk-extern -mharden-sls=all -mrecord-mcount
> -mfentry -march=x86-64 -g -O2 -std=gnu11 -p -fno-strict-aliasing
> -fno-common -fshort-wchar -fno-PIE -fcf-protection=none
> -falign-jumps=1 -falign-loops=1 -fno-asynchronous-unwind-tables
> -fno-jump-tables -fno-delete-null-pointer-checks
> -fno-allow-store-data-races -fstack-protector-strong
> -fno-stack-clash-protection -fzero-call-used-regs=used-gpr
> -fno-strict-overflow -fstack-check=no -fconserve-stack <921c0>
> DW_AT_language : 29 (C11) <921c1> DW_AT_name :
> (indirect line string, offset: 0x14b6):
> /root/git/linux/arch/x86/entry/syscall_64.c <921c5> DW_AT_comp_dir
> : (indirect line string, offset: 0):
> /root/git/build/v6.0.0+binutils-latest <921c9> DW_AT_stmt_list :
> 0x8110 <1><921cd>: Abbrev Number: 6 (DW_TAG_base_type) <921ce>
> DW_AT_byte_size : 8 <921cf> DW_AT_encoding : 7 (unsigned)
> <921d0> DW_AT_name : (indirect string, offset: 0x4dc4): long
> unsigned int
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
[not found] ` <Yz7bevBJAm0JiLfp@kernel.org>
@ 2022-10-06 14:00 ` Arnaldo Carvalho de Melo
2022-10-06 14:15 ` [PATCH/RFC pahole] btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST was: " Arnaldo Carvalho de Melo
2022-10-06 16:04 ` Andrii Nakryiko
0 siblings, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-06 14:00 UTC (permalink / raw)
To: Martin Liška, Andrii Nakryiko, Yonghong Song; +Cc: dwarves, Nick Clifton
Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Oct 06, 2022 at 01:54:37PM +0200, Martin Liška escreveu:
> > On 10/5/22 17:43, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Oct 05, 2022 at 11:37:13AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > So I built and installed from
> > > git://sourceware.org/git/binutils-gdb.git, it got on /usr/local/bin,
> > > taking precedence above /usr/bin/, and didn't get any
> > > DW_TAG_unspecified_type:
>
> > Well, it's more trickier what gcc driver runs as a GAS even though you prefixed
> > /usr/local/bin.
>
> ok
> > $ echo '' | gcc -c -x c - --verbose 2>&1 | grep 'as\>'
> > /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/as -v --64 -o -.o /tmp/cclvchQd.s
> > Anyway, the easiest approach how to use a different gas is using -B gcc option, which
> > would search the location for 'as' binary:
> > $ pwd
> > /home/marxin/Programming/binutils/objdir/gas
> > $ ./as-new --version
> > GNU assembler (GNU Binutils) 2.39.50.20221004
> > ...
> > $ ln -s as-new as
> > $ gcc -Wp,-MMD,arch/x86/entry/.entry.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -c -o arch/x86/entry/entry.o arch/x86/entry/entry.S -g -B/home/marxin/Programming/binutils/objdir/gas
> >
> > (note I'm using make defconfig), and not I can see:
>
> 'make defconfig' doesn't produce DWARF, so I continued using my
> .config, moved the -B to right after 'gcc' in the above command line and
> finally get:
>
> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> Contents of the .debug_info section:
>
> Compilation Unit @ offset 0:
> Length: 0x35 (32-bit)
> Version: 5
> Unit Type: DW_UT_compile (1)
> Abbrev Offset: 0
> Pointer Size: 8
> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <d> DW_AT_stmt_list : 0
> <11> DW_AT_low_pc : 0
> <19> DW_AT_high_pc : 19
> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> <26> DW_AT_language : 32769 (MIPS assembler)
> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> <2d> DW_AT_external : 1
> <2d> DW_AT_type : <0x37>
> <2e> DW_AT_low_pc : 0
> <36> DW_AT_high_pc : 19
> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> <1><38>: Abbrev Number: 0
>
> 15e20ce2324a:~/git/linux #
>
> Which pahole -J barfs on:
>
> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> [1] UNKNOWN (anon) Unexpected kind for reference
> 15e20ce2324a:~/git/linux #
>
> But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> (MIPS assembler)) then it ignores it, so this is a workaround.
>
> 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> 15e20ce2324a:~/git/linux #
>
> Now I'm looking at how to get the BTF encoder grokking this.
This is what I came up with, Andrii, Yonghong, wdyt?
As an additional info clang 14 (haven't tested with other versions)
encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
there.
- Arnaldo
commit 15ec614672da043008df31aa6ee85ebc5105d4fd
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Tue Oct 4 18:22:53 2022 -0300
btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
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_CONST.
Testing it:
Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
gcc's -B option to point to the directory with the new as, that is built
as as-new, so make a symlink, ending up with:
15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
Contents of the .debug_info section:
Compilation Unit @ offset 0:
Length: 0x35 (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0
Pointer Size: 8
<0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d> DW_AT_stmt_list : 0
<11> DW_AT_low_pc : 0
<19> DW_AT_high_pc : 19
<1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
<1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
<22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
<26> DW_AT_language : 32769 (MIPS assembler)
<1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
<29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
<2d> DW_AT_external : 1
<2d> DW_AT_type : <0x37>
<2e> DW_AT_low_pc : 0
<36> DW_AT_high_pc : 19
<1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
<1><38>: Abbrev Number: 0
So we have that asm label encoded by GNU AS 2.39.50 as a
DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
Found 0 per-CPU variables!
Found 1 functions!
File ./arch/x86/entry/entry.o:
[1] CONST (anon) type_id=0
[2] FUNC_PROTO (anon) return=1 args=(void)
[3] FUNC entry_ibpb type_id=2
15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
entry_ibpb
15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
const void entry_ibpb(void);
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
[1] CONST '(anon)' type_id=0
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC 'entry_ibpb' type_id=2 linkage=static
15e20ce2324a:~/git/linux #
I think this is what can be done to avoid having to skip ASM DWARF when
gets widely used, i.e. binutils gets updated.
Reported-by: Martin Liška <mliska@suse.cz>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Yonghong Song <yhs@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/btf_encoder.c b/btf_encoder.c
index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
^ permalink raw reply related [flat|nested] 33+ messages in thread
* [PATCH/RFC pahole] btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST was: Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-06 14:00 ` Arnaldo Carvalho de Melo
@ 2022-10-06 14:15 ` Arnaldo Carvalho de Melo
2022-10-06 16:04 ` Andrii Nakryiko
1 sibling, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-06 14:15 UTC (permalink / raw)
To: Martin Liška, Andrii Nakryiko, Yonghong Song; +Cc: dwarves, Nick Clifton
Just resending with a more informative subject line.
Andrii, Yonghong, if you could please check this and share your
opinions, that would be greatly appreciated.
- Arnaldo
Em Thu, Oct 06, 2022 at 11:00:20AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Oct 06, 2022 at 01:54:37PM +0200, Martin Liška escreveu:
> > > On 10/5/22 17:43, Arnaldo Carvalho de Melo wrote:
> > > > Em Wed, Oct 05, 2022 at 11:37:13AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > So I built and installed from
> > > > git://sourceware.org/git/binutils-gdb.git, it got on /usr/local/bin,
> > > > taking precedence above /usr/bin/, and didn't get any
> > > > DW_TAG_unspecified_type:
> >
> > > Well, it's more trickier what gcc driver runs as a GAS even though you prefixed
> > > /usr/local/bin.
> >
> > ok
>
> > > $ echo '' | gcc -c -x c - --verbose 2>&1 | grep 'as\>'
> > > /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/as -v --64 -o -.o /tmp/cclvchQd.s
>
> > > Anyway, the easiest approach how to use a different gas is using -B gcc option, which
> > > would search the location for 'as' binary:
>
> > > $ pwd
> > > /home/marxin/Programming/binutils/objdir/gas
> > > $ ./as-new --version
> > > GNU assembler (GNU Binutils) 2.39.50.20221004
> > > ...
> > > $ ln -s as-new as
> > > $ gcc -Wp,-MMD,arch/x86/entry/.entry.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -c -o arch/x86/entry/entry.o arch/x86/entry/entry.S -g -B/home/marxin/Programming/binutils/objdir/gas
> > >
> > > (note I'm using make defconfig), and not I can see:
> >
> > 'make defconfig' doesn't produce DWARF, so I continued using my
> > .config, moved the -B to right after 'gcc' in the above command line and
> > finally get:
> >
> > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > Contents of the .debug_info section:
> >
> > Compilation Unit @ offset 0:
> > Length: 0x35 (32-bit)
> > Version: 5
> > Unit Type: DW_UT_compile (1)
> > Abbrev Offset: 0
> > Pointer Size: 8
> > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > <d> DW_AT_stmt_list : 0
> > <11> DW_AT_low_pc : 0
> > <19> DW_AT_high_pc : 19
> > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > <26> DW_AT_language : 32769 (MIPS assembler)
> > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > <2d> DW_AT_external : 1
> > <2d> DW_AT_type : <0x37>
> > <2e> DW_AT_low_pc : 0
> > <36> DW_AT_high_pc : 19
> > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > <1><38>: Abbrev Number: 0
> >
> > 15e20ce2324a:~/git/linux #
> >
> > Which pahole -J barfs on:
> >
> > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > [1] UNKNOWN (anon) Unexpected kind for reference
> > 15e20ce2324a:~/git/linux #
> >
> > But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> > (MIPS assembler)) then it ignores it, so this is a workaround.
> >
> > 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> > 15e20ce2324a:~/git/linux #
> >
> > Now I'm looking at how to get the BTF encoder grokking this.
>
> This is what I came up with, Andrii, Yonghong, wdyt?
>
> As an additional info clang 14 (haven't tested with other versions)
> encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
> there.
>
> - Arnaldo
commit 15ec614672da043008df31aa6ee85ebc5105d4fd
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Tue Oct 4 18:22:53 2022 -0300
btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
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_CONST.
Testing it:
Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
gcc's -B option to point to the directory with the new as, that is built
as as-new, so make a symlink, ending up with:
15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
Contents of the .debug_info section:
Compilation Unit @ offset 0:
Length: 0x35 (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0
Pointer Size: 8
<0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d> DW_AT_stmt_list : 0
<11> DW_AT_low_pc : 0
<19> DW_AT_high_pc : 19
<1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
<1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
<22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
<26> DW_AT_language : 32769 (MIPS assembler)
<1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
<29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
<2d> DW_AT_external : 1
<2d> DW_AT_type : <0x37>
<2e> DW_AT_low_pc : 0
<36> DW_AT_high_pc : 19
<1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
<1><38>: Abbrev Number: 0
So we have that asm label encoded by GNU AS 2.39.50 as a
DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
Found 0 per-CPU variables!
Found 1 functions!
File ./arch/x86/entry/entry.o:
[1] CONST (anon) type_id=0
[2] FUNC_PROTO (anon) return=1 args=(void)
[3] FUNC entry_ibpb type_id=2
15e20ce2324a:~/git/linux # pahole -F btf ./arch/x86/entry/entry.o
15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
entry_ibpb
15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
const void entry_ibpb(void);
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
[1] CONST '(anon)' type_id=0
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC 'entry_ibpb' type_id=2 linkage=static
15e20ce2324a:~/git/linux #
I think this is what can be done to avoid having to skip ASM DWARF when
gets widely used, i.e. binutils gets updated.
Reported-by: Martin Liška <mliska@suse.cz>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Yonghong Song <yhs@fb.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/btf_encoder.c b/btf_encoder.c
index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-06 14:00 ` Arnaldo Carvalho de Melo
2022-10-06 14:15 ` [PATCH/RFC pahole] btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST was: " Arnaldo Carvalho de Melo
@ 2022-10-06 16:04 ` Andrii Nakryiko
2022-10-06 17:23 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 33+ messages in thread
From: Andrii Nakryiko @ 2022-10-06 16:04 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Martin Liška, Yonghong Song, dwarves, Nick Clifton
On Thu, Oct 6, 2022 at 7:00 AM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Oct 06, 2022 at 01:54:37PM +0200, Martin Liška escreveu:
> > > On 10/5/22 17:43, Arnaldo Carvalho de Melo wrote:
> > > > Em Wed, Oct 05, 2022 at 11:37:13AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > So I built and installed from
> > > > git://sourceware.org/git/binutils-gdb.git, it got on /usr/local/bin,
> > > > taking precedence above /usr/bin/, and didn't get any
> > > > DW_TAG_unspecified_type:
> >
> > > Well, it's more trickier what gcc driver runs as a GAS even though you prefixed
> > > /usr/local/bin.
> >
> > ok
>
> > > $ echo '' | gcc -c -x c - --verbose 2>&1 | grep 'as\>'
> > > /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/as -v --64 -o -.o /tmp/cclvchQd.s
>
> > > Anyway, the easiest approach how to use a different gas is using -B gcc option, which
> > > would search the location for 'as' binary:
>
> > > $ pwd
> > > /home/marxin/Programming/binutils/objdir/gas
> > > $ ./as-new --version
> > > GNU assembler (GNU Binutils) 2.39.50.20221004
> > > ...
> > > $ ln -s as-new as
> > > $ gcc -Wp,-MMD,arch/x86/entry/.entry.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -c -o arch/x86/entry/entry.o arch/x86/entry/entry.S -g -B/home/marxin/Programming/binutils/objdir/gas
> > >
> > > (note I'm using make defconfig), and not I can see:
> >
> > 'make defconfig' doesn't produce DWARF, so I continued using my
> > .config, moved the -B to right after 'gcc' in the above command line and
> > finally get:
> >
> > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > Contents of the .debug_info section:
> >
> > Compilation Unit @ offset 0:
> > Length: 0x35 (32-bit)
> > Version: 5
> > Unit Type: DW_UT_compile (1)
> > Abbrev Offset: 0
> > Pointer Size: 8
> > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > <d> DW_AT_stmt_list : 0
> > <11> DW_AT_low_pc : 0
> > <19> DW_AT_high_pc : 19
> > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > <26> DW_AT_language : 32769 (MIPS assembler)
> > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > <2d> DW_AT_external : 1
> > <2d> DW_AT_type : <0x37>
> > <2e> DW_AT_low_pc : 0
> > <36> DW_AT_high_pc : 19
> > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > <1><38>: Abbrev Number: 0
> >
> > 15e20ce2324a:~/git/linux #
> >
> > Which pahole -J barfs on:
> >
> > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > [1] UNKNOWN (anon) Unexpected kind for reference
> > 15e20ce2324a:~/git/linux #
> >
> > But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> > (MIPS assembler)) then it ignores it, so this is a workaround.
> >
> > 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> > 15e20ce2324a:~/git/linux #
> >
> > Now I'm looking at how to get the BTF encoder grokking this.
>
> This is what I came up with, Andrii, Yonghong, wdyt?
>
Does `const void` make sense? Why not just keeping it as "void"?
"const void" might confuse tooling and BTF verifier in kernel, but I
haven't checked. Just trying to understand why we need extra "const".
> As an additional info clang 14 (haven't tested with other versions)
> encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
> there.
>
> - Arnaldo
>
> commit 15ec614672da043008df31aa6ee85ebc5105d4fd
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Tue Oct 4 18:22:53 2022 -0300
>
> btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
>
> 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_CONST.
>
> Testing it:
>
> Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
> gcc's -B option to point to the directory with the new as, that is built
> as as-new, so make a symlink, ending up with:
>
> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> Contents of the .debug_info section:
>
> Compilation Unit @ offset 0:
> Length: 0x35 (32-bit)
> Version: 5
> Unit Type: DW_UT_compile (1)
> Abbrev Offset: 0
> Pointer Size: 8
> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <d> DW_AT_stmt_list : 0
> <11> DW_AT_low_pc : 0
> <19> DW_AT_high_pc : 19
> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> <26> DW_AT_language : 32769 (MIPS assembler)
> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> <2d> DW_AT_external : 1
> <2d> DW_AT_type : <0x37>
> <2e> DW_AT_low_pc : 0
> <36> DW_AT_high_pc : 19
> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> <1><38>: Abbrev Number: 0
>
> So we have that asm label encoded by GNU AS 2.39.50 as a
> DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
> 0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
>
> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
> btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
> Found 0 per-CPU variables!
> Found 1 functions!
> File ./arch/x86/entry/entry.o:
> [1] CONST (anon) type_id=0
> [2] FUNC_PROTO (anon) return=1 args=(void)
> [3] FUNC entry_ibpb type_id=2
> 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
> entry_ibpb
> 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
> const void entry_ibpb(void);
> 15e20ce2324a:~/git/linux #
>
> 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
> [1] CONST '(anon)' type_id=0
> [2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
> [3] FUNC 'entry_ibpb' type_id=2 linkage=static
> 15e20ce2324a:~/git/linux #
>
> I think this is what can be done to avoid having to skip ASM DWARF when
> gets widely used, i.e. binutils gets updated.
>
> Reported-by: Martin Liška <mliska@suse.cz>
> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> diff --git a/btf_encoder.c b/btf_encoder.c
> index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-06 16:04 ` Andrii Nakryiko
@ 2022-10-06 17:23 ` Arnaldo Carvalho de Melo
2022-10-07 20:21 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-06 17:23 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Thu, Oct 06, 2022 at 09:04:58AM -0700, Andrii Nakryiko escreveu:
> On Thu, Oct 6, 2022 at 7:00 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > > Contents of the .debug_info section:
> > > Compilation Unit @ offset 0:
> > > Length: 0x35 (32-bit)
> > > Version: 5
> > > Unit Type: DW_UT_compile (1)
> > > Abbrev Offset: 0
> > > Pointer Size: 8
> > > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > > <d> DW_AT_stmt_list : 0
> > > <11> DW_AT_low_pc : 0
> > > <19> DW_AT_high_pc : 19
> > > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > > <26> DW_AT_language : 32769 (MIPS assembler)
> > > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > > <2d> DW_AT_external : 1
> > > <2d> DW_AT_type : <0x37>
> > > <2e> DW_AT_low_pc : 0
> > > <36> DW_AT_high_pc : 19
> > > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > > <1><38>: Abbrev Number: 0
> > > 15e20ce2324a:~/git/linux #
> > > Which pahole -J barfs on:
> > > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > > [1] UNKNOWN (anon) Unexpected kind for reference
> > > 15e20ce2324a:~/git/linux #
> > > But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> > > (MIPS assembler)) then it ignores it, so this is a workaround.
> > > 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> > > 15e20ce2324a:~/git/linux #
> > > Now I'm looking at how to get the BTF encoder grokking this.
> > This is what I came up with, Andrii, Yonghong, wdyt?
> Does `const void` make sense? Why not just keeping it as "void"?
> "const void" might confuse tooling and BTF verifier in kernel, but I
> haven't checked. Just trying to understand why we need extra "const".
I was trying to have an entry for that DW_TAG_unspecified_type type
instead of plain changing the type for entry_ibpb (a DW_TAG_subprogram)
straight to 0 (void).
I.e. we wouldn't lose that info that the return type for that "function"
(it was encoded as a DW_TAG_subprogram) isn't defined. Using straight
void would state that it doesn't return anything.
I couldn't find a way to use KCFLAGS to ask Kbuild to pass that -B flag
to gcc so that I could rebuild the whole kernel with it to check if the
build goes thru and then try booting with such BTF info.
- Arnaldo
> > As an additional info clang 14 (haven't tested with other versions)
> > encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
> > there.
> >
> > - Arnaldo
> >
> > commit 15ec614672da043008df31aa6ee85ebc5105d4fd
> > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Date: Tue Oct 4 18:22:53 2022 -0300
> >
> > btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
> >
> > 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_CONST.
> >
> > Testing it:
> >
> > Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
> > gcc's -B option to point to the directory with the new as, that is built
> > as as-new, so make a symlink, ending up with:
> >
> > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > Contents of the .debug_info section:
> >
> > Compilation Unit @ offset 0:
> > Length: 0x35 (32-bit)
> > Version: 5
> > Unit Type: DW_UT_compile (1)
> > Abbrev Offset: 0
> > Pointer Size: 8
> > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > <d> DW_AT_stmt_list : 0
> > <11> DW_AT_low_pc : 0
> > <19> DW_AT_high_pc : 19
> > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > <26> DW_AT_language : 32769 (MIPS assembler)
> > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > <2d> DW_AT_external : 1
> > <2d> DW_AT_type : <0x37>
> > <2e> DW_AT_low_pc : 0
> > <36> DW_AT_high_pc : 19
> > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > <1><38>: Abbrev Number: 0
> >
> > So we have that asm label encoded by GNU AS 2.39.50 as a
> > DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
> > 0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
> >
> > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
> > btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
> > Found 0 per-CPU variables!
> > Found 1 functions!
> > File ./arch/x86/entry/entry.o:
> > [1] CONST (anon) type_id=0
> > [2] FUNC_PROTO (anon) return=1 args=(void)
> > [3] FUNC entry_ibpb type_id=2
> > 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
> > entry_ibpb
> > 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
> > const void entry_ibpb(void);
> > 15e20ce2324a:~/git/linux #
> >
> > 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
> > [1] CONST '(anon)' type_id=0
> > [2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
> > [3] FUNC 'entry_ibpb' type_id=2 linkage=static
> > 15e20ce2324a:~/git/linux #
> >
> > I think this is what can be done to avoid having to skip ASM DWARF when
> > gets widely used, i.e. binutils gets updated.
> >
> > Reported-by: Martin Liška <mliska@suse.cz>
> > Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > Cc: Yonghong Song <yhs@fb.com>
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> >
> > diff --git a/btf_encoder.c b/btf_encoder.c
> > index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-06 17:23 ` Arnaldo Carvalho de Melo
@ 2022-10-07 20:21 ` Arnaldo Carvalho de Melo
2022-10-08 0:25 ` Yonghong Song
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-07 20:21 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Thu, Oct 06, 2022 at 02:23:16PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Oct 06, 2022 at 09:04:58AM -0700, Andrii Nakryiko escreveu:
> > On Thu, Oct 6, 2022 at 7:00 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > > > Contents of the .debug_info section:
>
> > > > Compilation Unit @ offset 0:
> > > > Length: 0x35 (32-bit)
> > > > Version: 5
> > > > Unit Type: DW_UT_compile (1)
> > > > Abbrev Offset: 0
> > > > Pointer Size: 8
> > > > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > > > <d> DW_AT_stmt_list : 0
> > > > <11> DW_AT_low_pc : 0
> > > > <19> DW_AT_high_pc : 19
> > > > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > > > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > > > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > > > <26> DW_AT_language : 32769 (MIPS assembler)
> > > > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > > > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > > > <2d> DW_AT_external : 1
> > > > <2d> DW_AT_type : <0x37>
> > > > <2e> DW_AT_low_pc : 0
> > > > <36> DW_AT_high_pc : 19
> > > > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > > > <1><38>: Abbrev Number: 0
>
> > > > 15e20ce2324a:~/git/linux #
>
> > > > Which pahole -J barfs on:
>
> > > > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > > > [1] UNKNOWN (anon) Unexpected kind for reference
> > > > 15e20ce2324a:~/git/linux #
>
> > > > But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> > > > (MIPS assembler)) then it ignores it, so this is a workaround.
>
> > > > 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> > > > 15e20ce2324a:~/git/linux #
>
> > > > Now I'm looking at how to get the BTF encoder grokking this.
>
> > > This is what I came up with, Andrii, Yonghong, wdyt?
>
> > Does `const void` make sense? Why not just keeping it as "void"?
> > "const void" might confuse tooling and BTF verifier in kernel, but I
> > haven't checked. Just trying to understand why we need extra "const".
>
> I was trying to have an entry for that DW_TAG_unspecified_type type
> instead of plain changing the type for entry_ibpb (a DW_TAG_subprogram)
> straight to 0 (void).
I think this is the best way forward at the moment, i.e. to just change
the type for such DW_TAG_subprogram to zero, aka void, losing this
information by default.
I'll have a --btf_encode_unspecified_type as this const void trick as an
opt-in, who knows if this ends up being useful :-)
- Arnaldo
> I.e. we wouldn't lose that info that the return type for that "function"
> (it was encoded as a DW_TAG_subprogram) isn't defined. Using straight
> void would state that it doesn't return anything.
>
> I couldn't find a way to use KCFLAGS to ask Kbuild to pass that -B flag
> to gcc so that I could rebuild the whole kernel with it to check if the
> build goes thru and then try booting with such BTF info.
>
> - Arnaldo
>
> > > As an additional info clang 14 (haven't tested with other versions)
> > > encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
> > > there.
> > >
> > > - Arnaldo
> > >
> > > commit 15ec614672da043008df31aa6ee85ebc5105d4fd
> > > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > Date: Tue Oct 4 18:22:53 2022 -0300
> > >
> > > btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
> > >
> > > 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_CONST.
> > >
> > > Testing it:
> > >
> > > Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
> > > gcc's -B option to point to the directory with the new as, that is built
> > > as as-new, so make a symlink, ending up with:
> > >
> > > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > > Contents of the .debug_info section:
> > >
> > > Compilation Unit @ offset 0:
> > > Length: 0x35 (32-bit)
> > > Version: 5
> > > Unit Type: DW_UT_compile (1)
> > > Abbrev Offset: 0
> > > Pointer Size: 8
> > > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > > <d> DW_AT_stmt_list : 0
> > > <11> DW_AT_low_pc : 0
> > > <19> DW_AT_high_pc : 19
> > > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > > <26> DW_AT_language : 32769 (MIPS assembler)
> > > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > > <2d> DW_AT_external : 1
> > > <2d> DW_AT_type : <0x37>
> > > <2e> DW_AT_low_pc : 0
> > > <36> DW_AT_high_pc : 19
> > > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > > <1><38>: Abbrev Number: 0
> > >
> > > So we have that asm label encoded by GNU AS 2.39.50 as a
> > > DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
> > > 0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
> > >
> > > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > > 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
> > > btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
> > > Found 0 per-CPU variables!
> > > Found 1 functions!
> > > File ./arch/x86/entry/entry.o:
> > > [1] CONST (anon) type_id=0
> > > [2] FUNC_PROTO (anon) return=1 args=(void)
> > > [3] FUNC entry_ibpb type_id=2
> > > 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
> > > entry_ibpb
> > > 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
> > > const void entry_ibpb(void);
> > > 15e20ce2324a:~/git/linux #
> > >
> > > 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
> > > [1] CONST '(anon)' type_id=0
> > > [2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
> > > [3] FUNC 'entry_ibpb' type_id=2 linkage=static
> > > 15e20ce2324a:~/git/linux #
> > >
> > > I think this is what can be done to avoid having to skip ASM DWARF when
> > > gets widely used, i.e. binutils gets updated.
> > >
> > > Reported-by: Martin Liška <mliska@suse.cz>
> > > Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > > Cc: Yonghong Song <yhs@fb.com>
> > > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > >
> > > diff --git a/btf_encoder.c b/btf_encoder.c
> > > index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
>
> --
>
> - Arnaldo
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-07 20:21 ` Arnaldo Carvalho de Melo
@ 2022-10-08 0:25 ` Yonghong Song
2022-10-10 12:06 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2022-10-08 0:25 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Andrii Nakryiko
Cc: Martin Liška, Yonghong Song, dwarves, Nick Clifton
On 10/7/22 1:21 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 06, 2022 at 02:23:16PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Oct 06, 2022 at 09:04:58AM -0700, Andrii Nakryiko escreveu:
>>> On Thu, Oct 6, 2022 at 7:00 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
>>>> Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
>>>>> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
>>>>> Contents of the .debug_info section:
>>
>>>>> Compilation Unit @ offset 0:
>>>>> Length: 0x35 (32-bit)
>>>>> Version: 5
>>>>> Unit Type: DW_UT_compile (1)
>>>>> Abbrev Offset: 0
>>>>> Pointer Size: 8
>>>>> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
>>>>> <d> DW_AT_stmt_list : 0
>>>>> <11> DW_AT_low_pc : 0
>>>>> <19> DW_AT_high_pc : 19
>>>>> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
>>>>> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
>>>>> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
>>>>> <26> DW_AT_language : 32769 (MIPS assembler)
>>>>> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
>>>>> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
>>>>> <2d> DW_AT_external : 1
>>>>> <2d> DW_AT_type : <0x37>
>>>>> <2e> DW_AT_low_pc : 0
>>>>> <36> DW_AT_high_pc : 19
>>>>> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
>>>>> <1><38>: Abbrev Number: 0
>>
>>>>> 15e20ce2324a:~/git/linux #
>>
>>>>> Which pahole -J barfs on:
>>
>>>>> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
>>>>> [1] UNKNOWN (anon) Unexpected kind for reference
>>>>> 15e20ce2324a:~/git/linux #
>>
>>>>> But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
>>>>> (MIPS assembler)) then it ignores it, so this is a workaround.
>>
>>>>> 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
>>>>> 15e20ce2324a:~/git/linux #
>>
>>>>> Now I'm looking at how to get the BTF encoder grokking this.
>>
>>>> This is what I came up with, Andrii, Yonghong, wdyt?
>>
>>> Does `const void` make sense? Why not just keeping it as "void"?
>>> "const void" might confuse tooling and BTF verifier in kernel, but I
>>> haven't checked. Just trying to understand why we need extra "const".
>>
>> I was trying to have an entry for that DW_TAG_unspecified_type type
>> instead of plain changing the type for entry_ibpb (a DW_TAG_subprogram)
>> straight to 0 (void).
>
> I think this is the best way forward at the moment, i.e. to just change
> the type for such DW_TAG_subprogram to zero, aka void, losing this
> information by default.
>
> I'll have a --btf_encode_unspecified_type as this const void trick as an
> opt-in, who knows if this ends up being useful :-)
For function entry_ibpb, actually the kernel has a prorotype,
include/asm/nospec-branch.h:extern void entry_ibpb(void);
But unfortunately since the function is defined in asm code.
The actual type information is not encoded in dwarf so pahole
does not have enough info from vmlinux dwarf to get func
types. The compiler does not generate func types based on
declarations.
This may prevent people from tracing functions defined in
asm code but this should be extremely rare.
So I agree that BTF type id 0 is probably the best choice.
>
> - Arnaldo
>
>> I.e. we wouldn't lose that info that the return type for that "function"
>> (it was encoded as a DW_TAG_subprogram) isn't defined. Using straight
>> void would state that it doesn't return anything.
>>
>> I couldn't find a way to use KCFLAGS to ask Kbuild to pass that -B flag
>> to gcc so that I could rebuild the whole kernel with it to check if the
>> build goes thru and then try booting with such BTF info.
>>
>> - Arnaldo
>>
>>>> As an additional info clang 14 (haven't tested with other versions)
>>>> encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
>>>> there.
>>>>
>>>> - Arnaldo
>>>>
>>>> commit 15ec614672da043008df31aa6ee85ebc5105d4fd
>>>> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
>>>> Date: Tue Oct 4 18:22:53 2022 -0300
>>>>
>>>> btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
>>>>
>>>> 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_CONST.
>>>>
>>>> Testing it:
>>>>
>>>> Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
>>>> gcc's -B option to point to the directory with the new as, that is built
>>>> as as-new, so make a symlink, ending up with:
>>>>
>>>> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
>>>> Contents of the .debug_info section:
>>>>
>>>> Compilation Unit @ offset 0:
>>>> Length: 0x35 (32-bit)
>>>> Version: 5
>>>> Unit Type: DW_UT_compile (1)
>>>> Abbrev Offset: 0
>>>> Pointer Size: 8
>>>> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
>>>> <d> DW_AT_stmt_list : 0
>>>> <11> DW_AT_low_pc : 0
>>>> <19> DW_AT_high_pc : 19
>>>> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
>>>> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
>>>> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
>>>> <26> DW_AT_language : 32769 (MIPS assembler)
>>>> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
>>>> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
>>>> <2d> DW_AT_external : 1
>>>> <2d> DW_AT_type : <0x37>
>>>> <2e> DW_AT_low_pc : 0
>>>> <36> DW_AT_high_pc : 19
>>>> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
>>>> <1><38>: Abbrev Number: 0
>>>>
>>>> So we have that asm label encoded by GNU AS 2.39.50 as a
>>>> DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
>>>> 0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
>>>>
>>>> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
>>>> 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
>>>> btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
>>>> Found 0 per-CPU variables!
>>>> Found 1 functions!
>>>> File ./arch/x86/entry/entry.o:
>>>> [1] CONST (anon) type_id=0
>>>> [2] FUNC_PROTO (anon) return=1 args=(void)
>>>> [3] FUNC entry_ibpb type_id=2
>>>> 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
>>>> entry_ibpb
>>>> 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
>>>> const void entry_ibpb(void);
>>>> 15e20ce2324a:~/git/linux #
>>>>
>>>> 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
>>>> [1] CONST '(anon)' type_id=0
>>>> [2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
>>>> [3] FUNC 'entry_ibpb' type_id=2 linkage=static
>>>> 15e20ce2324a:~/git/linux #
>>>>
>>>> I think this is what can be done to avoid having to skip ASM DWARF when
>>>> gets widely used, i.e. binutils gets updated.
>>>>
>>>> Reported-by: Martin Liška <mliska@suse.cz>
>>>> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
>>>> Cc: Yonghong Song <yhs@fb.com>
>>>> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>>>>
>>>> diff --git a/btf_encoder.c b/btf_encoder.c
>>>> index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
>>
>> --
>>
>> - Arnaldo
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-08 0:25 ` Yonghong Song
@ 2022-10-10 12:06 ` Arnaldo Carvalho de Melo
2022-10-10 20:08 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-10 12:06 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Fri, Oct 07, 2022 at 05:25:21PM -0700, Yonghong Song escreveu:
>
>
> On 10/7/22 1:21 PM, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 06, 2022 at 02:23:16PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Oct 06, 2022 at 09:04:58AM -0700, Andrii Nakryiko escreveu:
> > > > On Thu, Oct 6, 2022 at 7:00 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > > > Em Thu, Oct 06, 2022 at 10:43:22AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > > > > > Contents of the .debug_info section:
> > >
> > > > > > Compilation Unit @ offset 0:
> > > > > > Length: 0x35 (32-bit)
> > > > > > Version: 5
> > > > > > Unit Type: DW_UT_compile (1)
> > > > > > Abbrev Offset: 0
> > > > > > Pointer Size: 8
> > > > > > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > > > > > <d> DW_AT_stmt_list : 0
> > > > > > <11> DW_AT_low_pc : 0
> > > > > > <19> DW_AT_high_pc : 19
> > > > > > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > > > > > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > > > > > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > > > > > <26> DW_AT_language : 32769 (MIPS assembler)
> > > > > > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > > > > > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > > > > > <2d> DW_AT_external : 1
> > > > > > <2d> DW_AT_type : <0x37>
> > > > > > <2e> DW_AT_low_pc : 0
> > > > > > <36> DW_AT_high_pc : 19
> > > > > > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > > > > > <1><38>: Abbrev Number: 0
> > >
> > > > > > 15e20ce2324a:~/git/linux #
> > >
> > > > > > Which pahole -J barfs on:
> > >
> > > > > > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > > > > > [1] UNKNOWN (anon) Unexpected kind for reference
> > > > > > 15e20ce2324a:~/git/linux #
> > >
> > > > > > But if we ask it to exclude asm CUs (<26> DW_AT_language : 32769
> > > > > > (MIPS assembler)) then it ignores it, so this is a workaround.
> > >
> > > > > > 15e20ce2324a:~/git/linux # pahole --lang_exclude asm -V -J ./arch/x86/entry/entry.o
> > > > > > 15e20ce2324a:~/git/linux #
> > >
> > > > > > Now I'm looking at how to get the BTF encoder grokking this.
> > >
> > > > > This is what I came up with, Andrii, Yonghong, wdyt?
> > > > Does `const void` make sense? Why not just keeping it as "void"?
> > > > "const void" might confuse tooling and BTF verifier in kernel, but I
> > > > haven't checked. Just trying to understand why we need extra "const".
> > >
> > > I was trying to have an entry for that DW_TAG_unspecified_type type
> > > instead of plain changing the type for entry_ibpb (a DW_TAG_subprogram)
> > > straight to 0 (void).
> >
> > I think this is the best way forward at the moment, i.e. to just change
> > the type for such DW_TAG_subprogram to zero, aka void, losing this
> > information by default.
> >
> > I'll have a --btf_encode_unspecified_type as this const void trick as an
> > opt-in, who knows if this ends up being useful :-)
>
> For function entry_ibpb, actually the kernel has a prorotype,
>
> include/asm/nospec-branch.h:extern void entry_ibpb(void);
> But unfortunately since the function is defined in asm code.
> The actual type information is not encoded in dwarf so pahole
> does not have enough info from vmlinux dwarf to get func
> types. The compiler does not generate func types based on
> declarations.
Right
> This may prevent people from tracing functions defined in
> asm code but this should be extremely rare.
> So I agree that BTF type id 0 is probably the best choice.
Thanks for your comments, that is the way I'll do it.
> > - Arnaldo
> > > I.e. we wouldn't lose that info that the return type for that "function"
> > > (it was encoded as a DW_TAG_subprogram) isn't defined. Using straight
> > > void would state that it doesn't return anything.
> > >
> > > I couldn't find a way to use KCFLAGS to ask Kbuild to pass that -B flag
> > > to gcc so that I could rebuild the whole kernel with it to check if the
> > > build goes thru and then try booting with such BTF info.
> > >
> > > - Arnaldo
> > > > > As an additional info clang 14 (haven't tested with other versions)
> > > > > encodes such ASM Labels as DW_TAG_label and this thus isn't an issue
> > > > > there.
> > > > >
> > > > > - Arnaldo
> > > > >
> > > > > commit 15ec614672da043008df31aa6ee85ebc5105d4fd
> > > > > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > > > Date: Tue Oct 4 18:22:53 2022 -0300
> > > > >
> > > > > btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST
> > > > >
> > > > > 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_CONST.
> > > > >
> > > > > Testing it:
> > > > >
> > > > > Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
> > > > > gcc's -B option to point to the directory with the new as, that is built
> > > > > as as-new, so make a symlink, ending up with:
> > > > >
> > > > > 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> > > > > Contents of the .debug_info section:
> > > > >
> > > > > Compilation Unit @ offset 0:
> > > > > Length: 0x35 (32-bit)
> > > > > Version: 5
> > > > > Unit Type: DW_UT_compile (1)
> > > > > Abbrev Offset: 0
> > > > > Pointer Size: 8
> > > > > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > > > > <d> DW_AT_stmt_list : 0
> > > > > <11> DW_AT_low_pc : 0
> > > > > <19> DW_AT_high_pc : 19
> > > > > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > > > > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > > > > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > > > > <26> DW_AT_language : 32769 (MIPS assembler)
> > > > > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > > > > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > > > > <2d> DW_AT_external : 1
> > > > > <2d> DW_AT_type : <0x37>
> > > > > <2e> DW_AT_low_pc : 0
> > > > > <36> DW_AT_high_pc : 19
> > > > > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > > > > <1><38>: Abbrev Number: 0
> > > > >
> > > > > So we have that asm label encoded by GNU AS 2.39.50 as a
> > > > > DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
> > > > > 0x37 that we encode as a BTF_KIND_CONST pointing to 0 (void):
> > > > >
> > > > > 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> > > > > 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
> > > > > btf_encoder__new: './arch/x86/entry/entry.o' doesn't have '.data..percpu' section
> > > > > Found 0 per-CPU variables!
> > > > > Found 1 functions!
> > > > > File ./arch/x86/entry/entry.o:
> > > > > [1] CONST (anon) type_id=0
> > > > > [2] FUNC_PROTO (anon) return=1 args=(void)
> > > > > [3] FUNC entry_ibpb type_id=2
> > > > > 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
> > > > > entry_ibpb
> > > > > 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
> > > > > const void entry_ibpb(void);
> > > > > 15e20ce2324a:~/git/linux #
> > > > >
> > > > > 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
> > > > > [1] CONST '(anon)' type_id=0
> > > > > [2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
> > > > > [3] FUNC 'entry_ibpb' type_id=2 linkage=static
> > > > > 15e20ce2324a:~/git/linux #
> > > > >
> > > > > I think this is what can be done to avoid having to skip ASM DWARF when
> > > > > gets widely used, i.e. binutils gets updated.
> > > > >
> > > > > Reported-by: Martin Liška <mliska@suse.cz>
> > > > > Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > > > > Cc: Yonghong Song <yhs@fb.com>
> > > > > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > > >
> > > > > diff --git a/btf_encoder.c b/btf_encoder.c
> > > > > index 7ad3f29ef153d8d6..7e50ba711ccc14d6 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_CONST, 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);
> > >
> > > --
> > >
> > > - Arnaldo
> >
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-10 12:06 ` Arnaldo Carvalho de Melo
@ 2022-10-10 20:08 ` Arnaldo Carvalho de Melo
2022-10-10 20:19 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-10 20:08 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Mon, Oct 10, 2022 at 09:06:46AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Oct 07, 2022 at 05:25:21PM -0700, Yonghong Song escreveu:
> > For function entry_ibpb, actually the kernel has a prorotype,
> > include/asm/nospec-branch.h:extern void entry_ibpb(void);
> > But unfortunately since the function is defined in asm code.
> > The actual type information is not encoded in dwarf so pahole
> > does not have enough info from vmlinux dwarf to get func
> > types. The compiler does not generate func types based on
> > declarations.
> Right
> > This may prevent people from tracing functions defined in
> > asm code but this should be extremely rare.
> > So I agree that BTF type id 0 is probably the best choice.
>
> Thanks for your comments, that is the way I'll do it.
Done, some prep patches then the patch below.
If possible, please ack :-)
- Arnaldo
commit 3abc72d9d56ec0cbfffc1794d2bf5d527d1e88ba
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Mon Oct 10 11:20:07 2022 -0300
btf_encoder: Encode DW_TAG_unspecified_type returning routines as void
Since we don´t have how to encode this info in BTF, and from what we
saw, at least in this case:
Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
gcc's -B option to point to the directory with the new as, that is built
as as-new, so make a symlink, ending up with:
15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
Contents of the .debug_info section:
Compilation Unit @ offset 0:
Length: 0x35 (32-bit)
Version: 5
Unit Type: DW_UT_compile (1)
Abbrev Offset: 0
Pointer Size: 8
<0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d> DW_AT_stmt_list : 0
<11> DW_AT_low_pc : 0
<19> DW_AT_high_pc : 19
<1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
<1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
<22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
<26> DW_AT_language : 32769 (MIPS assembler)
<1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
<29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
<2d> DW_AT_external : 1
<2d> DW_AT_type : <0x37>
<2e> DW_AT_low_pc : 0
<36> DW_AT_high_pc : 19
<1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
<1><38>: Abbrev Number: 0
So we have that asm label encoded by GNU AS 2.39.50 as a
DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
0x37 that we convert to 0 (void):
15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
btf_encoder__new: 'entry.o' doesn't have '.data..percpu' section
Found 0 per-CPU variables!
Found 1 functions!
File entry.o:
[1] FUNC_PROTO (anon) return=0 args=(void)
[2] FUNC entry_ibpb type_id=1
15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
entry_ibpb
15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
void entry_ibpb(void);
15e20ce2324a:~/git/linux #
15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
[1] FUNC_PROTO '(anon)' ret_type_id=0 vlen=0
[2] FUNC 'entry_ibpb' type_id=1 linkage=static
15e20ce2324a:~/git/linux #
I think this is what can be done to avoid having to skip ASM DWARF when
gets widely used, i.e. binutils gets updated.
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Cc: Martin Liška <mliska@suse.cz>
Cc: Yonghong Song <yhs@meta.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/btf_encoder.c b/btf_encoder.c
index fb2ca77e2e9bf144..a5fa04a84ee246ee 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
}
}
+static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
+{
+ if (tag_type == 0)
+ return 0;
+
+ if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
+ // No provision for encoding this, turn it into void.
+ return 0;
+ }
+
+ return type_id_off + tag_type;
+}
+
static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct ftype *ftype, uint32_t type_id_off)
{
struct btf *btf = encoder->btf;
@@ -603,7 +616,7 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f
/* add btf_type for func_proto */
nr_params = ftype->nr_parms + (ftype->unspec_parms ? 1 : 0);
- type_id = ftype->tag.type == 0 ? 0 : type_id_off + ftype->tag.type;
+ type_id = btf_encoder__tag_type(encoder, type_id_off, ftype->tag.type);
id = btf__add_func_proto(btf, type_id);
if (id > 0) {
@@ -966,6 +979,15 @@ 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:
+ /* Just don't encode this for now, converting anything with this type to void (0) instead.
+ *
+ * If we end up needing to encode this, one possible hack is to do as follows, as "const void".
+ *
+ * Returning zero means we skipped encoding a DWARF type.
+ */
+ // btf_encoder__add_ref_type(encoder, BTF_KIND_CONST, 0, NULL, false);
+ return 0;
default:
fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n",
dwarf_tag_name(tag->tag), tag->tag, ref_type_id);
@@ -1487,7 +1509,7 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
{
uint32_t type_id_off = btf__type_cnt(encoder->btf) - 1;
struct llvm_annotation *annot;
- int btf_type_id, tag_type_id;
+ int btf_type_id, tag_type_id, skipped_types = 0;
uint32_t core_id;
struct function *fn;
struct tag *pos;
@@ -1510,8 +1532,13 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
cu__for_each_type(cu, core_id, pos) {
btf_type_id = btf_encoder__encode_tag(encoder, pos, type_id_off, conf_load);
+ if (btf_type_id == 0) {
+ ++skipped_types;
+ continue;
+ }
+
if (btf_type_id < 0 ||
- tag__check_id_drift(pos, core_id, btf_type_id, type_id_off)) {
+ tag__check_id_drift(pos, core_id, btf_type_id + skipped_types, type_id_off)) {
err = -1;
goto out;
}
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-10 20:08 ` Arnaldo Carvalho de Melo
@ 2022-10-10 20:19 ` Arnaldo Carvalho de Melo
2022-10-11 5:57 ` Yonghong Song
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-10 20:19 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Mon, Oct 10, 2022 at 05:08:26PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Oct 10, 2022 at 09:06:46AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Oct 07, 2022 at 05:25:21PM -0700, Yonghong Song escreveu:
> > > For function entry_ibpb, actually the kernel has a prorotype,
> > > include/asm/nospec-branch.h:extern void entry_ibpb(void);
> > > But unfortunately since the function is defined in asm code.
> > > The actual type information is not encoded in dwarf so pahole
> > > does not have enough info from vmlinux dwarf to get func
> > > types. The compiler does not generate func types based on
> > > declarations.
> > Right
>
> > > This may prevent people from tracing functions defined in
> > > asm code but this should be extremely rare.
> > > So I agree that BTF type id 0 is probably the best choice.
> >
> > Thanks for your comments, that is the way I'll do it.
>
> Done, some prep patches then the patch below.
>
> If possible, please ack :-)
Its all now on my 'next' branch at:
git://git.kernel.org/pub/scm/devel/pahole/pahole.git
https://github.com/acmel/dwarves.git
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next
> - Arnaldo
>
> commit 3abc72d9d56ec0cbfffc1794d2bf5d527d1e88ba
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Mon Oct 10 11:20:07 2022 -0300
>
> btf_encoder: Encode DW_TAG_unspecified_type returning routines as void
>
> Since we don´t have how to encode this info in BTF, and from what we
> saw, at least in this case:
>
> Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
> gcc's -B option to point to the directory with the new as, that is built
> as as-new, so make a symlink, ending up with:
>
> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
> Contents of the .debug_info section:
>
> Compilation Unit @ offset 0:
> Length: 0x35 (32-bit)
> Version: 5
> Unit Type: DW_UT_compile (1)
> Abbrev Offset: 0
> Pointer Size: 8
> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <d> DW_AT_stmt_list : 0
> <11> DW_AT_low_pc : 0
> <19> DW_AT_high_pc : 19
> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> <26> DW_AT_language : 32769 (MIPS assembler)
> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> <2d> DW_AT_external : 1
> <2d> DW_AT_type : <0x37>
> <2e> DW_AT_low_pc : 0
> <36> DW_AT_high_pc : 19
> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> <1><38>: Abbrev Number: 0
>
> So we have that asm label encoded by GNU AS 2.39.50 as a
> DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
> 0x37 that we convert to 0 (void):
>
> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
> 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
> btf_encoder__new: 'entry.o' doesn't have '.data..percpu' section
> Found 0 per-CPU variables!
> Found 1 functions!
> File entry.o:
> [1] FUNC_PROTO (anon) return=0 args=(void)
> [2] FUNC entry_ibpb type_id=1
> 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
> entry_ibpb
> 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
> void entry_ibpb(void);
> 15e20ce2324a:~/git/linux #
>
> 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
> [1] FUNC_PROTO '(anon)' ret_type_id=0 vlen=0
> [2] FUNC 'entry_ibpb' type_id=1 linkage=static
> 15e20ce2324a:~/git/linux #
>
> I think this is what can be done to avoid having to skip ASM DWARF when
> gets widely used, i.e. binutils gets updated.
>
> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
> Cc: Martin Liška <mliska@suse.cz>
> Cc: Yonghong Song <yhs@meta.com>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> diff --git a/btf_encoder.c b/btf_encoder.c
> index fb2ca77e2e9bf144..a5fa04a84ee246ee 100644
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
> }
> }
>
> +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
> +{
> + if (tag_type == 0)
> + return 0;
> +
> + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
> + // No provision for encoding this, turn it into void.
> + return 0;
> + }
> +
> + return type_id_off + tag_type;
> +}
> +
> static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct ftype *ftype, uint32_t type_id_off)
> {
> struct btf *btf = encoder->btf;
> @@ -603,7 +616,7 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f
>
> /* add btf_type for func_proto */
> nr_params = ftype->nr_parms + (ftype->unspec_parms ? 1 : 0);
> - type_id = ftype->tag.type == 0 ? 0 : type_id_off + ftype->tag.type;
> + type_id = btf_encoder__tag_type(encoder, type_id_off, ftype->tag.type);
>
> id = btf__add_func_proto(btf, type_id);
> if (id > 0) {
> @@ -966,6 +979,15 @@ 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:
> + /* Just don't encode this for now, converting anything with this type to void (0) instead.
> + *
> + * If we end up needing to encode this, one possible hack is to do as follows, as "const void".
> + *
> + * Returning zero means we skipped encoding a DWARF type.
> + */
> + // btf_encoder__add_ref_type(encoder, BTF_KIND_CONST, 0, NULL, false);
> + return 0;
> default:
> fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n",
> dwarf_tag_name(tag->tag), tag->tag, ref_type_id);
> @@ -1487,7 +1509,7 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
> {
> uint32_t type_id_off = btf__type_cnt(encoder->btf) - 1;
> struct llvm_annotation *annot;
> - int btf_type_id, tag_type_id;
> + int btf_type_id, tag_type_id, skipped_types = 0;
> uint32_t core_id;
> struct function *fn;
> struct tag *pos;
> @@ -1510,8 +1532,13 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
> cu__for_each_type(cu, core_id, pos) {
> btf_type_id = btf_encoder__encode_tag(encoder, pos, type_id_off, conf_load);
>
> + if (btf_type_id == 0) {
> + ++skipped_types;
> + continue;
> + }
> +
> if (btf_type_id < 0 ||
> - tag__check_id_drift(pos, core_id, btf_type_id, type_id_off)) {
> + tag__check_id_drift(pos, core_id, btf_type_id + skipped_types, type_id_off)) {
> err = -1;
> goto out;
> }
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-10 20:19 ` Arnaldo Carvalho de Melo
@ 2022-10-11 5:57 ` Yonghong Song
2022-10-11 13:45 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2022-10-11 5:57 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
On 10/10/22 1:19 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Oct 10, 2022 at 05:08:26PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Mon, Oct 10, 2022 at 09:06:46AM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Fri, Oct 07, 2022 at 05:25:21PM -0700, Yonghong Song escreveu:
>>>> For function entry_ibpb, actually the kernel has a prorotype,
>
>>>> include/asm/nospec-branch.h:extern void entry_ibpb(void);
>
>>>> But unfortunately since the function is defined in asm code.
>>>> The actual type information is not encoded in dwarf so pahole
>>>> does not have enough info from vmlinux dwarf to get func
>>>> types. The compiler does not generate func types based on
>>>> declarations.
>
>>> Right
>>
>>>> This may prevent people from tracing functions defined in
>>>> asm code but this should be extremely rare.
>>>> So I agree that BTF type id 0 is probably the best choice.
>>>
>>> Thanks for your comments, that is the way I'll do it.
>>
>> Done, some prep patches then the patch below.
>>
>> If possible, please ack :-)
>
> Its all now on my 'next' branch at:
>
> git://git.kernel.org/pub/scm/devel/pahole/pahole.git
> https://github.com/acmel/dwarves.git
>
> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=next
>
>> - Arnaldo
>>
>> commit 3abc72d9d56ec0cbfffc1794d2bf5d527d1e88ba
>> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
>> Date: Mon Oct 10 11:20:07 2022 -0300
>>
>> btf_encoder: Encode DW_TAG_unspecified_type returning routines as void
>>
>> Since we don´t have how to encode this info in BTF, and from what we
>> saw, at least in this case:
>>
>> Built binutils from git://sourceware.org/git/binutils-gdb.git, then used
>> gcc's -B option to point to the directory with the new as, that is built
>> as as-new, so make a symlink, ending up with:
>>
>> 15e20ce2324a:~/git/linux # readelf -wi ./arch/x86/entry/entry.o
>> Contents of the .debug_info section:
>>
>> Compilation Unit @ offset 0:
>> Length: 0x35 (32-bit)
>> Version: 5
>> Unit Type: DW_UT_compile (1)
>> Abbrev Offset: 0
>> Pointer Size: 8
>> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
>> <d> DW_AT_stmt_list : 0
>> <11> DW_AT_low_pc : 0
>> <19> DW_AT_high_pc : 19
>> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
>> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
>> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
>> <26> DW_AT_language : 32769 (MIPS assembler)
>> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
>> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
>> <2d> DW_AT_external : 1
>> <2d> DW_AT_type : <0x37>
>> <2e> DW_AT_low_pc : 0
>> <36> DW_AT_high_pc : 19
>> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
>> <1><38>: Abbrev Number: 0
>>
>> So we have that asm label encoded by GNU AS 2.39.50 as a
>> DW_TAG_subprogram that has as its DW_AT_type the DW_TAG_unspecified_type
>> 0x37 that we convert to 0 (void):
>>
>> 15e20ce2324a:~/git/linux # pahole -J ./arch/x86/entry/entry.o
>> 15e20ce2324a:~/git/linux # pahole -JV ./arch/x86/entry/entry.o
>> btf_encoder__new: 'entry.o' doesn't have '.data..percpu' section
>> Found 0 per-CPU variables!
>> Found 1 functions!
>> File entry.o:
>> [1] FUNC_PROTO (anon) return=0 args=(void)
>> [2] FUNC entry_ibpb type_id=1
>> 15e20ce2324a:~/git/linux # pfunct -F btf ./arch/x86/entry/entry.o
>> entry_ibpb
>> 15e20ce2324a:~/git/linux # pfunct --proto -F btf ./arch/x86/entry/entry.o
>> void entry_ibpb(void);
>> 15e20ce2324a:~/git/linux #
>>
>> 15e20ce2324a:~/git/linux # tools/bpf/bpftool/bpftool btf dump file ./arch/x86/entry/entry.o format raw
>> [1] FUNC_PROTO '(anon)' ret_type_id=0 vlen=0
>> [2] FUNC 'entry_ibpb' type_id=1 linkage=static
>> 15e20ce2324a:~/git/linux #
>>
>> I think this is what can be done to avoid having to skip ASM DWARF when
>> gets widely used, i.e. binutils gets updated.
>>
>> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
>> Cc: Martin Liška <mliska@suse.cz>
>> Cc: Yonghong Song <yhs@meta.com>
>> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>>
>> diff --git a/btf_encoder.c b/btf_encoder.c
>> index fb2ca77e2e9bf144..a5fa04a84ee246ee 100644
>> --- a/btf_encoder.c
>> +++ b/btf_encoder.c
>> @@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
>> }
>> }
>>
>> +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
>> +{
>> + if (tag_type == 0)
>> + return 0;
>> +
>> + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
Why we need tag_type == encoder->cu->unspecified_type.type?
Should we unconditionally convert an unspecified_type to btf type id 0?
>> + // No provision for encoding this, turn it into void.
>> + return 0;
>> + }
>> +
>> + return type_id_off + tag_type;
>> +}
>> +
>> static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct ftype *ftype, uint32_t type_id_off)
>> {
>> struct btf *btf = encoder->btf;
>> @@ -603,7 +616,7 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f
>>
>> /* add btf_type for func_proto */
>> nr_params = ftype->nr_parms + (ftype->unspec_parms ? 1 : 0);
>> - type_id = ftype->tag.type == 0 ? 0 : type_id_off + ftype->tag.type;
>> + type_id = btf_encoder__tag_type(encoder, type_id_off, ftype->tag.type);
>>
>> id = btf__add_func_proto(btf, type_id);
>> if (id > 0) {
>> @@ -966,6 +979,15 @@ 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:
>> + /* Just don't encode this for now, converting anything with this type to void (0) instead.
>> + *
>> + * If we end up needing to encode this, one possible hack is to do as follows, as "const void".
>> + *
>> + * Returning zero means we skipped encoding a DWARF type.
>> + */
>> + // btf_encoder__add_ref_type(encoder, BTF_KIND_CONST, 0, NULL, false);
>> + return 0;
>> default:
>> fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n",
>> dwarf_tag_name(tag->tag), tag->tag, ref_type_id);
>> @@ -1487,7 +1509,7 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
>> {
>> uint32_t type_id_off = btf__type_cnt(encoder->btf) - 1;
>> struct llvm_annotation *annot;
>> - int btf_type_id, tag_type_id;
>> + int btf_type_id, tag_type_id, skipped_types = 0;
>> uint32_t core_id;
>> struct function *fn;
>> struct tag *pos;
>> @@ -1510,8 +1532,13 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
>> cu__for_each_type(cu, core_id, pos) {
>> btf_type_id = btf_encoder__encode_tag(encoder, pos, type_id_off, conf_load);
>>
>> + if (btf_type_id == 0) {
>> + ++skipped_types;
>> + continue;
>> + }
>> +
>> if (btf_type_id < 0 ||
>> - tag__check_id_drift(pos, core_id, btf_type_id, type_id_off)) {
>> + tag__check_id_drift(pos, core_id, btf_type_id + skipped_types, type_id_off)) {
>> err = -1;
>> goto out;
>> }
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-11 5:57 ` Yonghong Song
@ 2022-10-11 13:45 ` Arnaldo Carvalho de Melo
2022-10-11 15:33 ` Yonghong Song
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-11 13:45 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Mon, Oct 10, 2022 at 10:57:24PM -0700, Yonghong Song escreveu:
> On 10/10/22 1:19 PM, Arnaldo Carvalho de Melo wrote:
> > > +++ b/btf_encoder.c
> > > @@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
> > > }
> > > }
> > > +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
> > > +{
> > > + if (tag_type == 0)
> > > + return 0;
> > > +
> > > + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
>
> Why we need tag_type == encoder->cu->unspecified_type.type?
> Should we unconditionally convert an unspecified_type to btf type id 0?
right, that is what is being done on that line, see,
DW_TAG_unspecified_type isn't some constant, what we have as the type in
functions in DWARF is the ID for that DW_TAG_unspecified_type for that
specific CU, see:
<0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
<d> DW_AT_stmt_list : 0
<11> DW_AT_low_pc : 0
<19> DW_AT_high_pc : 19
<1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
<1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
<22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
<26> DW_AT_language : 32769 (MIPS assembler)
<1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
<29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
<2d> DW_AT_external : 1
<2d> DW_AT_type : <0x37>
<2e> DW_AT_low_pc : 0
<36> DW_AT_high_pc : 19
<1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
<1><38>: Abbrev Number: 0
Look at the info for entry_ibpb, there is no DW_TAG_unspecified_type
there, what it has is 0x37 as its type. We have to go see what that type
is, it could be DW_TAG_pointer_type with a DW_AT_type pointing to the
real type (or a series of references via DW_TAG_const_type,
DW_TAG_volatile_type, etc).
So in the DWARF loader we record if we have a DW_TAG_unspecified_type in
the current CU and what is its "small id", which won't be 0x37, as we
use an array for types, to compress the ID space.
Then, at the btf_encoding phase we look at functions type, and if it
matches the DW_TAG_unspecified_type type for that specific CU, then we
convert it to void.
- Arnaldo
> > > + // No provision for encoding this, turn it into void.
> > > + return 0;
> > > + }
> > > +
> > > + return type_id_off + tag_type;
> > > +}
> > > +
> > > static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct ftype *ftype, uint32_t type_id_off)
> > > {
> > > struct btf *btf = encoder->btf;
> > > @@ -603,7 +616,7 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f
> > > /* add btf_type for func_proto */
> > > nr_params = ftype->nr_parms + (ftype->unspec_parms ? 1 : 0);
> > > - type_id = ftype->tag.type == 0 ? 0 : type_id_off + ftype->tag.type;
> > > + type_id = btf_encoder__tag_type(encoder, type_id_off, ftype->tag.type);
> > > id = btf__add_func_proto(btf, type_id);
> > > if (id > 0) {
> > > @@ -966,6 +979,15 @@ 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:
> > > + /* Just don't encode this for now, converting anything with this type to void (0) instead.
> > > + *
> > > + * If we end up needing to encode this, one possible hack is to do as follows, as "const void".
> > > + *
> > > + * Returning zero means we skipped encoding a DWARF type.
> > > + */
> > > + // btf_encoder__add_ref_type(encoder, BTF_KIND_CONST, 0, NULL, false);
> > > + return 0;
> > > default:
> > > fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n",
> > > dwarf_tag_name(tag->tag), tag->tag, ref_type_id);
> > > @@ -1487,7 +1509,7 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
> > > {
> > > uint32_t type_id_off = btf__type_cnt(encoder->btf) - 1;
> > > struct llvm_annotation *annot;
> > > - int btf_type_id, tag_type_id;
> > > + int btf_type_id, tag_type_id, skipped_types = 0;
> > > uint32_t core_id;
> > > struct function *fn;
> > > struct tag *pos;
> > > @@ -1510,8 +1532,13 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
> > > cu__for_each_type(cu, core_id, pos) {
> > > btf_type_id = btf_encoder__encode_tag(encoder, pos, type_id_off, conf_load);
> > > + if (btf_type_id == 0) {
> > > + ++skipped_types;
> > > + continue;
> > > + }
> > > +
> > > if (btf_type_id < 0 ||
> > > - tag__check_id_drift(pos, core_id, btf_type_id, type_id_off)) {
> > > + tag__check_id_drift(pos, core_id, btf_type_id + skipped_types, type_id_off)) {
> > > err = -1;
> > > goto out;
> > > }
> >
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-11 13:45 ` Arnaldo Carvalho de Melo
@ 2022-10-11 15:33 ` Yonghong Song
2022-10-11 17:16 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2022-10-11 15:33 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
On 10/11/22 6:45 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Oct 10, 2022 at 10:57:24PM -0700, Yonghong Song escreveu:
>> On 10/10/22 1:19 PM, Arnaldo Carvalho de Melo wrote:
>>>> +++ b/btf_encoder.c
>>>> @@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
>>>> }
>>>> }
>>>> +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
>>>> +{
>>>> + if (tag_type == 0)
>>>> + return 0;
>>>> +
>>>> + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
>>
>> Why we need tag_type == encoder->cu->unspecified_type.type?
>> Should we unconditionally convert an unspecified_type to btf type id 0?
>
> right, that is what is being done on that line, see,
> DW_TAG_unspecified_type isn't some constant, what we have as the type in
> functions in DWARF is the ID for that DW_TAG_unspecified_type for that
> specific CU, see:
>
> <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <d> DW_AT_stmt_list : 0
> <11> DW_AT_low_pc : 0
> <19> DW_AT_high_pc : 19
> <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> <26> DW_AT_language : 32769 (MIPS assembler)
> <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> <2d> DW_AT_external : 1
> <2d> DW_AT_type : <0x37>
> <2e> DW_AT_low_pc : 0
> <36> DW_AT_high_pc : 19
> <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> <1><38>: Abbrev Number: 0
>
> Look at the info for entry_ibpb, there is no DW_TAG_unspecified_type
> there, what it has is 0x37 as its type. We have to go see what that type
> is, it could be DW_TAG_pointer_type with a DW_AT_type pointing to the
> real type (or a series of references via DW_TAG_const_type,
> DW_TAG_volatile_type, etc).
>
> So in the DWARF loader we record if we have a DW_TAG_unspecified_type in
> the current CU and what is its "small id", which won't be 0x37, as we
> use an array for types, to compress the ID space.
>
> Then, at the btf_encoding phase we look at functions type, and if it
> matches the DW_TAG_unspecified_type type for that specific CU, then we
> convert it to void.
Thanks for explanation. Now I understand.
encoder->cu->unspecified_type.tag indicates that at cu level, we have an
unspecified type.
encoder->cu->unspecified_type.type records the unspecified_type
small_id. I assume this should be okay since compiler did dedup
within the cu so we should have only one unspecified type per cu.
tag_type == encoder->cu->unspecified_type.type ensures the
current btf type should expect the unspecified type before it
can be considered as an unspecified type.
Acked-by: Yonghong Song <yhs@fb.com>
>
> - Arnaldo
>
>>>> + // No provision for encoding this, turn it into void.
>>>> + return 0;
>>>> + }
>>>> +
>>>> + return type_id_off + tag_type;
>>>> +}
>>>> +
>>>> static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct ftype *ftype, uint32_t type_id_off)
>>>> {
>>>> struct btf *btf = encoder->btf;
>>>> @@ -603,7 +616,7 @@ static int32_t btf_encoder__add_func_proto(struct btf_encoder *encoder, struct f
>>>> /* add btf_type for func_proto */
>>>> nr_params = ftype->nr_parms + (ftype->unspec_parms ? 1 : 0);
>>>> - type_id = ftype->tag.type == 0 ? 0 : type_id_off + ftype->tag.type;
>>>> + type_id = btf_encoder__tag_type(encoder, type_id_off, ftype->tag.type);
>>>> id = btf__add_func_proto(btf, type_id);
>>>> if (id > 0) {
>>>> @@ -966,6 +979,15 @@ 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:
>>>> + /* Just don't encode this for now, converting anything with this type to void (0) instead.
>>>> + *
>>>> + * If we end up needing to encode this, one possible hack is to do as follows, as "const void".
>>>> + *
>>>> + * Returning zero means we skipped encoding a DWARF type.
>>>> + */
>>>> + // btf_encoder__add_ref_type(encoder, BTF_KIND_CONST, 0, NULL, false);
>>>> + return 0;
>>>> default:
>>>> fprintf(stderr, "Unsupported DW_TAG_%s(0x%x): type: 0x%x\n",
>>>> dwarf_tag_name(tag->tag), tag->tag, ref_type_id);
>>>> @@ -1487,7 +1509,7 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
>>>> {
>>>> uint32_t type_id_off = btf__type_cnt(encoder->btf) - 1;
>>>> struct llvm_annotation *annot;
>>>> - int btf_type_id, tag_type_id;
>>>> + int btf_type_id, tag_type_id, skipped_types = 0;
>>>> uint32_t core_id;
>>>> struct function *fn;
>>>> struct tag *pos;
>>>> @@ -1510,8 +1532,13 @@ int btf_encoder__encode_cu(struct btf_encoder *encoder, struct cu *cu, struct co
>>>> cu__for_each_type(cu, core_id, pos) {
>>>> btf_type_id = btf_encoder__encode_tag(encoder, pos, type_id_off, conf_load);
>>>> + if (btf_type_id == 0) {
>>>> + ++skipped_types;
>>>> + continue;
>>>> + }
>>>> +
>>>> if (btf_type_id < 0 ||
>>>> - tag__check_id_drift(pos, core_id, btf_type_id, type_id_off)) {
>>>> + tag__check_id_drift(pos, core_id, btf_type_id + skipped_types, type_id_off)) {
>>>> err = -1;
>>>> goto out;
>>>> }
>>>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-11 15:33 ` Yonghong Song
@ 2022-10-11 17:16 ` Arnaldo Carvalho de Melo
2023-01-30 9:23 ` Martin Liška
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-10-11 17:16 UTC (permalink / raw)
To: Yonghong Song
Cc: Andrii Nakryiko, Martin Liška, Yonghong Song, dwarves, Nick Clifton
Em Tue, Oct 11, 2022 at 08:33:34AM -0700, Yonghong Song escreveu:
>
>
> On 10/11/22 6:45 AM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Oct 10, 2022 at 10:57:24PM -0700, Yonghong Song escreveu:
> > > On 10/10/22 1:19 PM, Arnaldo Carvalho de Melo wrote:
> > > > > +++ b/btf_encoder.c
> > > > > @@ -593,6 +593,19 @@ static int32_t btf_encoder__add_func_param(struct btf_encoder *encoder, const ch
> > > > > }
> > > > > }
> > > > > +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type)
> > > > > +{
> > > > > + if (tag_type == 0)
> > > > > + return 0;
> > > > > +
> > > > > + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) {
> > >
> > > Why we need tag_type == encoder->cu->unspecified_type.type?
> > > Should we unconditionally convert an unspecified_type to btf type id 0?
> >
> > right, that is what is being done on that line, see,
> > DW_TAG_unspecified_type isn't some constant, what we have as the type in
> > functions in DWARF is the ID for that DW_TAG_unspecified_type for that
> > specific CU, see:
> > <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit)
> > <d> DW_AT_stmt_list : 0
> > <11> DW_AT_low_pc : 0
> > <19> DW_AT_high_pc : 19
> > <1a> DW_AT_name : (indirect string, offset: 0): arch/x86/entry/entry.S
> > <1e> DW_AT_comp_dir : (indirect string, offset: 0x17): /root/git/linux
> > <22> DW_AT_producer : (indirect string, offset: 0x27): GNU AS 2.39.50
> > <26> DW_AT_language : 32769 (MIPS assembler)
> > <1><28>: Abbrev Number: 2 (DW_TAG_subprogram)
> > <29> DW_AT_name : (indirect string, offset: 0x36): entry_ibpb
> > <2d> DW_AT_external : 1
> > <2d> DW_AT_type : <0x37>
> > <2e> DW_AT_low_pc : 0
> > <36> DW_AT_high_pc : 19
> > <1><37>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> > <1><38>: Abbrev Number: 0
> > Look at the info for entry_ibpb, there is no DW_TAG_unspecified_type
> > there, what it has is 0x37 as its type. We have to go see what that type
> > is, it could be DW_TAG_pointer_type with a DW_AT_type pointing to the
> > real type (or a series of references via DW_TAG_const_type,
> > DW_TAG_volatile_type, etc).
> > So in the DWARF loader we record if we have a DW_TAG_unspecified_type in
> > the current CU and what is its "small id", which won't be 0x37, as we
> > use an array for types, to compress the ID space.
> > Then, at the btf_encoding phase we look at functions type, and if it
> > matches the DW_TAG_unspecified_type type for that specific CU, then we
> > convert it to void.
> Thanks for explanation. Now I understand.
> encoder->cu->unspecified_type.tag indicates that at cu level, we have an
> unspecified type.
> encoder->cu->unspecified_type.type records the unspecified_type small_id. I
> assume this should be okay since compiler did dedup
> within the cu so we should have only one unspecified type per cu.
Yes, that is my assumption as well, that a CU will have just one
DW_TAG_unspecified_type, lemme confirm this by finding some other ASM
CU with more than one "function".
> tag_type == encoder->cu->unspecified_type.type ensures the
> current btf type should expect the unspecified type before it
> can be considered as an unspecified type.
> Acked-by: Yonghong Song <yhs@fb.com>
Thanks!
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2022-10-11 17:16 ` Arnaldo Carvalho de Melo
@ 2023-01-30 9:23 ` Martin Liška
2023-01-30 14:20 ` pahole 1.25 plans was: " Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Martin Liška @ 2023-01-30 9:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Yonghong Song
Cc: Andrii Nakryiko, Yonghong Song, dwarves, Nick Clifton
Hi Arnaldo.
Now as the binutils 2.40 release is out, can you please consider doing a new
dwarvers (pahole) release that will include the changes we discussed in this thread?
Thank you,
Martin
^ permalink raw reply [flat|nested] 33+ messages in thread
* pahole 1.25 plans was: Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2023-01-30 9:23 ` Martin Liška
@ 2023-01-30 14:20 ` Arnaldo Carvalho de Melo
2023-03-12 0:03 ` Dominique Martinet
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2023-01-30 14:20 UTC (permalink / raw)
To: Martin Liška
Cc: Yonghong Song, Andrii Nakryiko, Yonghong Song, dwarves,
Nick Clifton, Alan Maguire
Em Mon, Jan 30, 2023 at 10:23:02AM +0100, Martin Liška escreveu:
> Hi Arnaldo.
>
> Now as the binutils 2.40 release is out, can you please consider doing a new
> dwarvers (pahole) release that will include the changes we discussed in this thread?
I hoped to finish the work on split dwarf (.dwz) before cutting a new
version, but I'm postponing it to 1.26, so just cherry-picked some
patches from the 'next' branch and I'm doing some more tests before
cutting a new version.
But then there is also the series by Alan Maguire that needs to get into
1.25, so I'll try and check the current status of that thread and test
it.
Yonghong, comments?
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: pahole 1.25 plans was: Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
2023-01-30 14:20 ` pahole 1.25 plans was: " Arnaldo Carvalho de Melo
@ 2023-03-12 0:03 ` Dominique Martinet
0 siblings, 0 replies; 33+ messages in thread
From: Dominique Martinet @ 2023-03-12 0:03 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Martin Liška, Yonghong Song, Andrii Nakryiko, Yonghong Song,
dwarves, Nick Clifton, Alan Maguire
Hi Arnaldo,
Arnaldo Carvalho de Melo wrote on Mon, Jan 30, 2023 at 11:20:20AM -0300:
> I hoped to finish the work on split dwarf (.dwz) before cutting a new
> version, but I'm postponing it to 1.26, so just cherry-picked some
> patches from the 'next' branch and I'm doing some more tests before
> cutting a new version.
>
> But then there is also the series by Alan Maguire that needs to get into
> 1.25, so I'll try and check the current status of that thread and test
> it.
(I think the patches from Alan Maguire got in?)
nixos has had to upgrade pahole to a version from git for binutils 2.40,
and there are some incompatibilities with the linux 6.3-rc1 build at the
very least so a new tag would be well appreciated for cleaning this all
up.
What's the current plan?
Cheers,
--
Dominique Martinet | Asmadeus
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2023-03-12 0:03 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-03 8:56 Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b) Martin Liška
2022-10-03 12:07 ` Nick Clifton
2022-10-04 12:15 ` Arnaldo Carvalho de Melo
2022-10-04 12:17 ` Arnaldo Carvalho de Melo
2022-10-04 12:31 ` Arnaldo Carvalho de Melo
2022-10-04 21:42 ` Arnaldo Carvalho de Melo
2022-10-05 8:41 ` Martin Liška
2022-10-04 12:33 ` Nick Clifton
2022-10-04 13:25 ` Arnaldo Carvalho de Melo
2022-10-04 18:07 ` Arnaldo Carvalho de Melo
2022-10-04 21:13 ` Arnaldo Carvalho de Melo
2022-10-04 21:44 ` Arnaldo Carvalho de Melo
2022-10-05 7:23 ` Martin Liška
2022-10-05 14:37 ` Arnaldo Carvalho de Melo
2022-10-05 15:43 ` Arnaldo Carvalho de Melo
2022-10-06 11:54 ` Martin Liška
[not found] ` <Yz7bevBJAm0JiLfp@kernel.org>
2022-10-06 14:00 ` Arnaldo Carvalho de Melo
2022-10-06 14:15 ` [PATCH/RFC pahole] btf_encoder: Encode DW_TAG_unspecified_type as BTF_KIND_CONST was: " Arnaldo Carvalho de Melo
2022-10-06 16:04 ` Andrii Nakryiko
2022-10-06 17:23 ` Arnaldo Carvalho de Melo
2022-10-07 20:21 ` Arnaldo Carvalho de Melo
2022-10-08 0:25 ` Yonghong Song
2022-10-10 12:06 ` Arnaldo Carvalho de Melo
2022-10-10 20:08 ` Arnaldo Carvalho de Melo
2022-10-10 20:19 ` Arnaldo Carvalho de Melo
2022-10-11 5:57 ` Yonghong Song
2022-10-11 13:45 ` Arnaldo Carvalho de Melo
2022-10-11 15:33 ` Yonghong Song
2022-10-11 17:16 ` Arnaldo Carvalho de Melo
2023-01-30 9:23 ` Martin Liška
2023-01-30 14:20 ` pahole 1.25 plans was: " Arnaldo Carvalho de Melo
2023-03-12 0:03 ` Dominique Martinet
2022-10-05 16:55 ` Arnaldo Carvalho de Melo
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.