bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Yonghong Song <yhs@fb.com>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next] selftests/bpf: fix btf_dump __int128 test failure with clang build kernel
Date: Fri, 24 Sep 2021 16:35:08 -0700	[thread overview]
Message-ID: <CAEf4BzZtcWginbqcaSG9ywm6y_juHowbQf2auNn5YLc9zpGfWw@mail.gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.23.451.2109241911100.21067@localhost>

On Fri, Sep 24, 2021 at 11:13 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> On Fri, 24 Sep 2021, Yonghong Song wrote:
>
> > With clang build kernel (adding LLVM=1 to kernel and selftests/bpf build
> > command line), I hit the following test failure:
> >
> >   $ ./test_progs -t btf_dump
> >   ...
> >   btf_dump_data:PASS:ensure expected/actual match 0 nsec
> >   btf_dump_data:FAIL:find type id unexpected find type id: actual -2 < expected 0
> >   btf_dump_data:FAIL:find type id unexpected find type id: actual -2 < expected 0
> >   test_btf_dump_int_data:FAIL:dump __int128 unexpected error: -2 (errno 2)
> >   #15/9 btf_dump/btf_dump: int_data:FAIL
> >
> > Further analysis showed gcc build kernel has type "__int128" in dwarf/BTF
> > and it doesn't exist in clang build kernel. Code searching for kernel code
> > found the following:
> >   arch/s390/include/asm/types.h:  unsigned __int128 pair;
> >   crypto/ecc.c:   unsigned __int128 m = (unsigned __int128)left * right;
> >   include/linux/math64.h: return (u64)(((unsigned __int128)a * mul) >> shift);
> >   include/linux/math64.h: return (u64)(((unsigned __int128)a * mul) >> shift);
> >   lib/ubsan.h:typedef __int128 s_max;
> >   lib/ubsan.h:typedef unsigned __int128 u_max;
> >
> > In my case, CONFIG_UBSAN is not enabled. Even if we only have "unsigned __int128"
> > in the code, somehow gcc still put "__int128" in dwarf while clang didn't.
> > Hence current test works fine for gcc but not for clang.
> >
> > Enabling CONFIG_UBSAN is an option to provide __int128 type into dwarf
> > reliably for both gcc and clang, but not everybody enables CONFIG_UBSAN
> > in their kernel build. So the best choice is to use "unsigned __int128" type
> > which is available in both clang and gcc build kernels. But clang and gcc
> > dwarf encoded names for "unsigned __int128" are different:
> >
> >   [$ ~] cat t.c
> >   unsigned __int128 a;
> >   [$ ~] gcc -g -c t.c && llvm-dwarfdump t.o | grep __int128
> >                   DW_AT_type      (0x00000031 "__int128 unsigned")
> >                   DW_AT_name      ("__int128 unsigned")
> >   [$ ~] clang -g -c t.c && llvm-dwarfdump t.o | grep __int128
> >                   DW_AT_type      (0x00000033 "unsigned __int128")
> >                   DW_AT_name      ("unsigned __int128")
> >
> > The test change in this patch tries to test type name before
> > doing actual test.
> >
>
> Thanks for finding and fixing this!
>
> > Signed-off-by: Yonghong Song <yhs@fb.com>
>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
>

Applied to bpf-next, thanks.

> > ---
> >  .../selftests/bpf/prog_tests/btf_dump.c       | 27 ++++++++++++++-----
> >  1 file changed, 21 insertions(+), 6 deletions(-)
> >

[...]

      reply	other threads:[~2021-09-24 23:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24  2:58 [PATCH bpf-next] selftests/bpf: fix btf_dump __int128 test failure with clang build kernel Yonghong Song
2021-09-24 18:12 ` Alan Maguire
2021-09-24 23:35   ` Andrii Nakryiko [this message]

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=CAEf4BzZtcWginbqcaSG9ywm6y_juHowbQf2auNn5YLc9zpGfWw@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.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).