From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Yonghong Song <yhs@fb.com>,
dwarves@vger.kernel.org, bpf@vger.kernel.org, andriin@fb.com,
mark@klomp.org, Nick Desaulniers <ndesaulniers@google.com>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH dwarves v2] btf_encoder: sanitize non-regular int base type
Date: Mon, 8 Feb 2021 16:55:01 -0300 [thread overview]
Message-ID: <20210208195501.GS920417@kernel.org> (raw)
In-Reply-To: <CA+icZUVwz+OroPfsqtOxAstWGeRxf=KYMUY5LCDPzyPLJFmZmg@mail.gmail.com>
Em Sun, Feb 07, 2021 at 11:32:00AM +0100, Sedat Dilek escreveu:
> On Sun, Feb 7, 2021 at 8:17 AM Yonghong Song <yhs@fb.com> wrote:
> >
> > clang with dwarf5 may generate non-regular int base type,
> > i.e., not a signed/unsigned char/short/int/longlong/__int128.
> > Such base types are often used to describe
> > how an actual parameter or variable is generated. For example,
> >
> > 0x000015cf: DW_TAG_base_type
> > DW_AT_name ("DW_ATE_unsigned_1")
> > DW_AT_encoding (DW_ATE_unsigned)
> > DW_AT_byte_size (0x00)
> >
> > 0x00010ed9: DW_TAG_formal_parameter
> > DW_AT_location (DW_OP_lit0,
> > DW_OP_not,
> > DW_OP_convert (0x000015cf) "DW_ATE_unsigned_1",
> > DW_OP_convert (0x000015d4) "DW_ATE_unsigned_8",
> > DW_OP_stack_value)
> > DW_AT_abstract_origin (0x00013984 "branch")
> >
> > What it does is with a literal "0", did a "not" operation, and the converted to
> > one-bit unsigned int and then 8-bit unsigned int.
> >
> > Another example,
> >
> > 0x000e97e4: DW_TAG_base_type
> > DW_AT_name ("DW_ATE_unsigned_24")
> > DW_AT_encoding (DW_ATE_unsigned)
> > DW_AT_byte_size (0x03)
> >
> > 0x000f88f8: DW_TAG_variable
> > DW_AT_location (indexed (0x3c) loclist = 0x00008fb0:
> > [0xffffffff82808812, 0xffffffff82808817):
> > DW_OP_breg0 RAX+0,
> > DW_OP_convert (0x000e97d5) "DW_ATE_unsigned_64",
> > DW_OP_convert (0x000e97df) "DW_ATE_unsigned_8",
> > DW_OP_stack_value,
> > DW_OP_piece 0x1,
> > DW_OP_breg0 RAX+0,
> > DW_OP_convert (0x000e97d5) "DW_ATE_unsigned_64",
> > DW_OP_convert (0x000e97da) "DW_ATE_unsigned_32",
> > DW_OP_lit8,
> > DW_OP_shr,
> > DW_OP_convert (0x000e97da) "DW_ATE_unsigned_32",
> > DW_OP_convert (0x000e97e4) "DW_ATE_unsigned_24",
> > DW_OP_stack_value,
> > DW_OP_piece 0x3
> > ......
> >
> > At one point, a right shift by 8 happens and the result is converted to
> > 32-bit unsigned int and then to 24-bit unsigned int.
> >
> > BTF does not need any of these DW_OP_* information and such non-regular int
> > types will cause libbpf to emit errors.
> > Let us sanitize them to generate BTF acceptable to libbpf and kernel.
> >
> > Cc: Sedat Dilek <sedat.dilek@gmail.com>
>
> Thanks for v2.
>
> For both v1 and v2:
>
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Thanks, applied.
- Arnaldo
> My development and testing environment:
>
> 1. Debian/testing AMD64
> 2. Linux v5.11-rc6+ with custom mostly Clang fixes
> 3. Debug-Info: BTF + DWARF-v5 enabled
> 4. Compiler and tools (incl. Clang's Integrated ASsembler IAS):
> LLVM/Clang v12.0.0-rc1 (make LLVM=1 LLVM_IAS=1)
>
> Build and boot on bare metal.
>
> - Sedat -
>
> > Acked-by: Andrii Nakryiko <andrii@kernel.org>
> > Signed-off-by: Yonghong Song <yhs@fb.com>
> > ---
> > libbtf.c | 39 ++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 38 insertions(+), 1 deletion(-)
> >
> > diff --git a/libbtf.c b/libbtf.c
> > index 9f76283..5843200 100644
> > --- a/libbtf.c
> > +++ b/libbtf.c
> > @@ -373,6 +373,7 @@ int32_t btf_elf__add_base_type(struct btf_elf *btfe, const struct base_type *bt,
> > struct btf *btf = btfe->btf;
> > const struct btf_type *t;
> > uint8_t encoding = 0;
> > + uint16_t byte_sz;
> > int32_t id;
> >
> > if (bt->is_signed) {
> > @@ -384,7 +385,43 @@ int32_t btf_elf__add_base_type(struct btf_elf *btfe, const struct base_type *bt,
> > return -1;
> > }
> >
> > - id = btf__add_int(btf, name, BITS_ROUNDUP_BYTES(bt->bit_size), encoding);
> > + /* dwarf5 may emit DW_ATE_[un]signed_{num} base types where
> > + * {num} is not power of 2 and may exceed 128. Such attributes
> > + * are mostly used to record operation for an actual parameter
> > + * or variable.
> > + * For example,
> > + * DW_AT_location (indexed (0x3c) loclist = 0x00008fb0:
> > + * [0xffffffff82808812, 0xffffffff82808817):
> > + * DW_OP_breg0 RAX+0,
> > + * DW_OP_convert (0x000e97d5) "DW_ATE_unsigned_64",
> > + * DW_OP_convert (0x000e97df) "DW_ATE_unsigned_8",
> > + * DW_OP_stack_value,
> > + * DW_OP_piece 0x1,
> > + * DW_OP_breg0 RAX+0,
> > + * DW_OP_convert (0x000e97d5) "DW_ATE_unsigned_64",
> > + * DW_OP_convert (0x000e97da) "DW_ATE_unsigned_32",
> > + * DW_OP_lit8,
> > + * DW_OP_shr,
> > + * DW_OP_convert (0x000e97da) "DW_ATE_unsigned_32",
> > + * DW_OP_convert (0x000e97e4) "DW_ATE_unsigned_24",
> > + * DW_OP_stack_value, DW_OP_piece 0x3
> > + * DW_AT_name ("ebx")
> > + * DW_AT_decl_file ("/linux/arch/x86/events/intel/core.c")
> > + *
> > + * In the above example, at some point, one unsigned_32 value
> > + * is right shifted by 8 and the result is converted to unsigned_32
> > + * and then unsigned_24.
> > + *
> > + * BTF does not need such DW_OP_* information so let us sanitize
> > + * these non-regular int types to avoid libbpf/kernel complaints.
> > + */
> > + byte_sz = BITS_ROUNDUP_BYTES(bt->bit_size);
> > + if (!byte_sz || (byte_sz & (byte_sz - 1))) {
> > + name = "__SANITIZED_FAKE_INT__";
> > + byte_sz = 4;
> > + }
> > +
> > + id = btf__add_int(btf, name, byte_sz, encoding);
> > if (id < 0) {
> > btf_elf__log_err(btfe, BTF_KIND_INT, name, true, "Error emitting BTF type");
> > } else {
> > --
> > 2.24.1
> >
--
- Arnaldo
next prev parent reply other threads:[~2021-02-08 19:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-07 7:17 [PATCH dwarves v2] btf_encoder: sanitize non-regular int base type Yonghong Song
2021-02-07 10:32 ` Sedat Dilek
2021-02-08 19:55 ` Arnaldo Carvalho de Melo [this message]
2021-02-08 20:46 ` Sedat Dilek
2021-02-08 21:07 ` Andrii Nakryiko
2021-02-08 21:11 ` Sedat Dilek
2021-02-07 14:18 ` Mark Wielaard
2021-02-07 15:15 ` Sedat Dilek
2021-02-07 18:14 ` Yonghong Song
2021-02-08 19:16 ` Nick Desaulniers
[not found] ` <CAMXQf9_Qy5tD05ax1vtETnzM9szLxm95JgpHgT0HzjktixMNNQ@mail.gmail.com>
2021-02-08 21:24 ` Mark Wielaard
2021-02-08 19:22 ` Nick Desaulniers
2021-02-08 19:27 ` Sedat Dilek
2021-02-08 20:13 ` 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=20210208195501.GS920417@kernel.org \
--to=acme@kernel.org \
--cc=andrii@kernel.org \
--cc=andriin@fb.com \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=mark@klomp.org \
--cc=ndesaulniers@google.com \
--cc=sedat.dilek@gmail.com \
--cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).