diff options
author | Andrii Nakryiko <andriin@fb.com> | 2020-07-13 16:24:08 -0700 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2020-07-13 17:07:43 -0700 |
commit | 7c819e701382d4969ca4837b8cbe157895f5d0bf (patch) | |
tree | 46a48d1f8ea402e2848f8ccbb5b44a6c1d66bf62 /tools/lib/bpf/libbpf.c | |
parent | 207a573c04755d5ef83e89ee1b3e4941f000acbd (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