[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

ast added a comment. In D133361#4637008 , @eddyz87 wrote: > In D133361#4629292 , @ast wrote: > >> ... >> Right. Such recursive propagation of PAI is necessary. For btf_tag we cannot >> do it. Always propagating

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

eddyz87 added a comment. In D133361#4629292 , @ast wrote: > ... > Right. Such recursive propagation of PAI is necessary. For btf_tag we cannot > do it. Always propagating it won't be correct. > New preserve_const_field_offset would need to be propagated

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

eddyz87 added a comment. After retesting kernel build with LLVM=1 and libbpf patch to reconstruct btf_decl_tag [1], statistics for BPF selftests looks as follows: - out of 653 object files 13 have some differences with and w/o this change;

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

ast added a comment. In D133361#4629081 , @eddyz87 wrote: > Note on current propagation logic: whenever there is an expression E of type > T, where T is a struct annotated with btf_decl_tag("ctx"), all usages of E > are traversed recursively visiting

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

eddyz87 added a comment. In D133361#4628951 , @ast wrote: > I agree that it's not useful outside of BPF, but it's useful outside of > 'ctx'. I think 'preserve_constant_field_offset' would be more accurate > description of the restriction. > We can

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

ast added a comment. > I can rename these things, but tbh I don't think this functionality would be > useful anywhere outside BPF, thus such renaming would be kind-of deceptive > (and in case it would be useful, the renaming could be done at the time of > second use). I agree that it's not

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

yonghong-song added a comment. > I can rename these things, but tbh I don't think this functionality would be > useful anywhere outside BPF, thus such renaming would be kind-of deceptive > (and in case it would be useful, the renaming could be done at the time of > second use). Then let us

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

eddyz87 added inline comments. Comment at: llvm/include/llvm/IR/Intrinsics.td:2432 ImmArg>]>; +def int_context_marker_bpf : DefaultAttrsIntrinsic<[llvm_ptr_ty], + [llvm_ptr_ty],

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

yonghong-song added a comment. I will try to review other parts of code in the next few days. Comment at: llvm/include/llvm/IR/Intrinsics.td:2432 ImmArg>]>; +def int_context_marker_bpf : DefaultAttrsIntrinsic<[llvm_ptr_ty], +

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

eddyz87 added inline comments. Comment at: llvm/include/llvm/IR/Intrinsics.td:2432 ImmArg>]>; +def int_context_marker_bpf : DefaultAttrsIntrinsic<[llvm_ptr_ty], + [llvm_ptr_ty],

[PATCH] D133361: [BPF] Attribute btf_decl_tag("ctx") for structs

yonghong-song added inline comments. Comment at: llvm/include/llvm/IR/Intrinsics.td:2432 ImmArg>]>; +def int_context_marker_bpf : DefaultAttrsIntrinsic<[llvm_ptr_ty], +