From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Yonghong Song <yhs@meta.com>
Cc: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
"Martin Liška" <mliska@suse.cz>, "Yonghong Song" <yhs@fb.com>,
dwarves@vger.kernel.org, "Nick Clifton" <nickc@redhat.com>
Subject: Re: Encountered error while encoding BTF due to Unsupported DW_TAG_unspecified_type(0x3b)
Date: Mon, 10 Oct 2022 09:06:46 -0300 [thread overview]
Message-ID: <Y0QK1nmVjqr95od1@kernel.org> (raw)
In-Reply-To: <166780df-a8ca-6dfb-88e9-9e489efc6bf7@meta.com>
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
next prev parent reply other threads:[~2022-10-10 12:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0QK1nmVjqr95od1@kernel.org \
--to=acme@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=dwarves@vger.kernel.org \
--cc=mliska@suse.cz \
--cc=nickc@redhat.com \
--cc=yhs@fb.com \
--cc=yhs@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox