summaryrefslogtreecommitdiff
path: root/tools/lib/bpf/libbpf.c
diff options
context:
space:
mode:
authorAndrii Nakryiko <andriin@fb.com>2020-07-13 16:24:08 -0700
committerAlexei Starovoitov <ast@kernel.org>2020-07-13 17:07:43 -0700
commit7c819e701382d4969ca4837b8cbe157895f5d0bf (patch)
tree46a48d1f8ea402e2848f8ccbb5b44a6c1d66bf62 /tools/lib/bpf/libbpf.c
parent207a573c04755d5ef83e89ee1b3e4941f000acbd (diff)
libbpf: Support stripping modifiers for btf_dump
One important use case when emitting const/volatile/restrict is undesirable is BPF skeleton generation of DATASEC layout. These are further memory-mapped and can be written/read from user-space directly. For important case of .rodata variables, bpftool strips away first-level modifiers, to make their use on user-space side simple and not requiring extra type casts to override compiler complaining about writing to const variables. This logic works mostly fine, but breaks in some more complicated cases. E.g.: const volatile int params[10]; Because in BTF it's a chain of ARRAY -> CONST -> VOLATILE -> INT, bpftool stops at ARRAY and doesn't strip CONST and VOLATILE. In skeleton this variable will be emitted as is. So when used from user-space, compiler will complain about writing to const array. This is problematic, as also mentioned in [0]. To solve this for arrays and other non-trivial cases (e.g., inner const/volatile fields inside the struct), teach btf_dump to strip away any modifier, when requested. This is done as an extra option on btf_dump__emit_type_decl() API. Reported-by: Anton Protopopov <a.s.protopopov@gmail.com> Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200713232409.3062144-2-andriin@fb.com
Diffstat (limited to 'tools/lib/bpf/libbpf.c')
0 files changed, 0 insertions, 0 deletions