summaryrefslogtreecommitdiff
path: root/tools/bpf
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2021-03-18 22:40:31 +0300
committerAlexei Starovoitov <ast@kernel.org>2021-03-19 02:14:22 +0300
commit8fd27bf69b864b1c2a6e64cf5673603f3959a6ef (patch)
treea5da4b78d943f3ef4e809ae50d79d1ba322d08ce /tools/bpf
parentfaf6ed321cf61fafa17444fe01e7e336b8e89acc (diff)
downloadlinux-8fd27bf69b864b1c2a6e64cf5673603f3959a6ef.tar.xz
libbpf: Add BPF static linker BTF and BTF.ext support
Add .BTF and .BTF.ext static linking logic. When multiple BPF object files are linked together, their respective .BTF and .BTF.ext sections are merged together. BTF types are not just concatenated, but also deduplicated. .BTF.ext data is grouped by type (func info, line info, core_relos) and target section names, and then all the records are concatenated together, preserving their relative order. All the BTF type ID references and string offsets are updated as necessary, to take into account possibly deduplicated strings and types. BTF DATASEC types are handled specially. Their respective var_secinfos are accumulated separately in special per-section data and then final DATASEC types are emitted at the very end during bpf_linker__finalize() operation, just before emitting final ELF output file. BTF data can also provide "section annotations" for some extern variables. Such concept is missing in ELF, but BTF will have DATASEC types for such special extern datasections (e.g., .kconfig, .ksyms). Such sections are called "ephemeral" internally. Internally linker will keep metadata for each such section, collecting variables information, but those sections won't be emitted into the final ELF file. Also, given LLVM/Clang during compilation emits BTF DATASECS that are incomplete, missing section size and variable offsets for static variables, BPF static linker will initially fix up such DATASECs, using ELF symbols data. The final DATASECs will preserve section sizes and all variable offsets. This is handled correctly by libbpf already, so won't cause any new issues. On the other hand, it's actually a nice property to have a complete BTF data without runtime adjustments done during bpf_object__open() by libbpf. In that sense, BPF static linker is also a BTF normalizer. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210318194036.3521577-8-andrii@kernel.org
Diffstat (limited to 'tools/bpf')
0 files changed, 0 insertions, 0 deletions