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

Eduard Zingerman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 30 11:31:08 PDT 2023


eddyz87 added a comment.

In D133361#4628951 <https://reviews.llvm.org/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 expand in the doc that it's a constant offset when field of the struct is accessed.
>
> Also instead of btf_tag it would be better to add another builtin similar to preserve_access_index.
> Currently we add __attribute__((preserve_access_index)) to trigger CO-RE.
> This one will be a new __attribute__((preserve_constant_field_offset)) that will be specified manually either in uapi/bpf.h or in vmlinux.h on some structs

This makes sense, I'll adjust the implementation to use new attribute (also will try to use metadata instead of intrinsic call, replace by intrinsic on the back-end side).

> and it will have precedence over preserve_access_index, so
> (__attribute__((preserve_access_index)), apply_to = record) in vmlinux.h will be ignored on such structs.
> Otherwise it's a bit odd that special names inside btf_tag have stronger rules than other __attribute__((preserve_access_index)).

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 `getelementptr` and calls to `preserve_{struct,union,array}_index`, the latter are replaced by `getelementptr`. E.g.:

  #define __pai __attribute__((preserve_access_context));
  #define __ctx __attribute__((btf_decl_tag("ctx")))
  struct bar { int a; int b; } __pai;
  struct foo {
    struct bar b;
  } __ctx __pai;
  ... struct foo f; ...
  ... f.b.bb ...

The call to `preserve_struct_index` generated for `bb` in `f.b.bb` would be replaced by `getelementptr` and later by `getelementptr.and.load`.
However, context structures don't have nested structures at the moment. The list of context structures is:

- __sk_buff
- bpf_cgroup_dev_ctx
- bpf_sk_lookup
- bpf_sock
- bpf_sock_addr
- bpf_sock_ops
- bpf_sockopt
- bpf_sysctl
- sk_msg_md
- sk_reuseport_md
- xdp_md


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133361



More information about the llvm-commits mailing list