[PATCH] D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function

[Andrii Nakryiko via Phabricator via llvm-commits]

anakryiko added a comment.

In D74668#2020554 <https://reviews.llvm.org/D74668#2020554>, @yonghong-song wrote:

> In D74668#2019558 <https://reviews.llvm.org/D74668#2019558>, @anakryiko wrote:
>
> > what's the use case for flag==0 (no relocation)? why using built-in at all in such case? Also flag==1 means relocate to local BTF ID or remote (kernel) BTF ID? Do you plan to add flag=2 as well to cover both cases? Or am I misunderstanding the meaning of this flag?
>
>
> Originally, I thought flag = 0 for the following use case:
>
>    e.g., they just want to know the type of a particular local structure for pretty print purpose.
>    Note that currently only types for global/extern variables, function parameters are recorded in btf.
>      int test() {
>         struct { int a; int b; ...} ctx;
>         btf_id = __builtin_btf_type_id(ctx, 0);
>         bpf_seq_write(seq, &btf_id, sizeof(btf_id));
>         bpf_seq_write(seq, &ctx, sizeof(ctx));
>         ...
>      }
>   
>   But obviously without relocation, this will not work with btf deduplication, future static linking etc.


Right, that's what I was thinking. We should have relocation always, even if it's a noop for libbpf today.

> flag 1: for relocation. My original thinking is for vmlinux relocation.
> 
>          
> 
> I think you brought a good point about local relocation, so will need
>  to change the flag to:
> 
>   flag 0 : local relocation
>   flag 1:  vmlinux relocation
>    
> 
> Two more relocation types will be generated:
> 
>   BTF_TYPE_ID_LOCAL
>   BTF_TYPE_ID_REMOTE

Yep, that would be great.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74668/new/

https://reviews.llvm.org/D74668