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 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.