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