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: Tue, 11 Oct 2022 14:16:22 -0300 [thread overview]
Message-ID: <Y0Wk5i0Zz2saSKK3@kernel.org> (raw)
In-Reply-To: <ee52054a-bd76-2817-33c4-ffae00e72fb9@meta.com>
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
next prev parent reply other threads:[~2022-10-11 17:16 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
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 [this message]
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=Y0Wk5i0Zz2saSKK3@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