archive mirror
 help / color / mirror / Atom feed
From: Alan Maguire <>
To: Yonghong Song <>
Cc: Alan Maguire <>,,,,,,,,,,,,,,,,,,
Subject: Re: [PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers
Date: Sun, 6 Dec 2020 00:43:36 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LRH.2.23.451.2012060038260.1505@localhost> (raw)
In-Reply-To: <>

On Sat, 5 Dec 2020, Yonghong Song wrote:

> __builtin_btf_type_id() is really only supported in llvm12
> and 64bit return value support is pushed to llvm12 trunk
> a while back. The builtin is introduced in llvm11 but has a
> corner bug, so llvm12 is recommended. So if people use the builtin,
> you can assume 64bit return value. libbpf support is required
> here. So in my opinion, there is no need to do feature detection.
> Andrii has a patch to support 64bit return value for
> __builtin_btf_type_id() and I assume that one should
> be landed before or together with your patch.
> Just for your info. The following is an example you could
> use to determine whether __builtin_btf_type_id()
> supports btf object id at llvm level.
> -bash-4.4$ cat t.c
> int test(int arg) {
>   return __builtin_btf_type_id(arg, 1);
> }
> Compile to generate assembly code with latest llvm12 trunk:
>   clang -target bpf -O2 -S -g -mcpu=v3 t.c
> In the asm code, you should see one line with
>   r0 = 1 ll
> Or you can generate obj code:
>   clang -target bpf -O2 -c -g -mcpu=v3 t.c
> and then you disassemble the obj file
>   llvm-objdump -d --no-show-raw-insn --no-leading-addr t.o
> You should see below in the output
>   r0 = 1 ll
> Use earlier version of llvm12 trunk, the builtin has
> 32bit return value, you will see
>   r0 = 1
> which is a 32bit imm to r0, while "r0 = 1 ll" is
> 64bit imm to r0.

Thanks for this Yonghong!  I'm thinking the way I'll tackle it
is to simply verify that the upper 32 bits specifying the
veth module object id are non-zero; if they are zero, we'll skip
the test (I think a skip probably makes sense as not everyone will
have llvm12). Does that seem reasonable?

With the additional few minor changes on top of Andrii's patch,
the use of __builtin_btf_type_id() worked perfectly. Thanks!


  parent reply	other threads:[~2020-12-06  0:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 18:48 Alan Maguire
2020-12-04 18:48 ` [PATCH v2 bpf-next 1/3] bpf: eliminate btf_module_mutex as RCU synchronization can be used Alan Maguire
2020-12-04 18:48 ` [PATCH v2 bpf-next 2/3] bpf: add module support to btf display helpers Alan Maguire
2020-12-04 18:48 ` [PATCH v2 bpf-next 3/3] selftests/bpf: verify module-specific types can be shown via bpf_snprintf_btf Alan Maguire
2020-12-05 20:35 ` [PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers Yonghong Song
2020-12-05 20:39   ` Yonghong Song
2020-12-06  0:43   ` Alan Maguire [this message]
2020-12-07  3:38     ` Yonghong Song
2020-12-08  3:42     ` Andrii Nakryiko

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.23.451.2012060038260.1505@localhost \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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