Re: [PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers

From: Yonghong Song
Date: Sun Dec 06 2020 - 22:40:08 EST




On 12/5/20 4:43 PM, Alan Maguire wrote:

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?

This should work too and we do not need to add a note in
README.rst for this test then.


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

Alan