https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113453
Bug ID: 113453
Summary: bpf: func_info and line_info missing in .BTF.ext
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cupertino.miranda at oracle dot com
Target Milestone: ---
This is a placeholder for the implementation for func_info and line_info
content in .BTF.ext section, required in particular cases by the kernel
verifier.
For the particular case of func_info, it is a required when get identified as a
BPF_PSEUDO_FUNC.
# if (insn->src_reg == BPF_PSEUDO_FUNC) {
# ...
# if (!aux->func_info) {
# verbose(env, "missing btf func_info\n");
# return -EINVAL;
# }
Which gets triggered by the following code:
# /* mark the insn, so it's recognized by insn_is_pseudo_func() */
# if (relo->type == RELO_SUBPROG_ADDR)
# insn[0].src_reg = BPF_PSEUDO_FUNC;
Documentation for the content of .BTF.ext can be found in:
- https://docs.kernel.org/bpf/btf.html
func_info keeps a record of all entry point addresses and section to any
BTF_KIND_FUNC entry. By traversing the func_info content the BPF infrastructure
can recover code location for any BTF_KIND_FUNC.
A few requirements to note for the implementation are, as mentioned in
documentation:
for func_info:
- func_info[0].insn_off must be 0.
- the func_info insn_off is in strictly increasing order and matches bpf func
boundaries.
for line_info:
- the first insn in each func must have a line_info record pointing to it.
- the line_info insn_off is in strictly increasing order.
Other observations are that function entry symbol relocation in the func_info
require that all relocations in func_info should be resolved within the object
file (resolved by gas), relative to the function section symbol.
This was observed in the content of the clang objects.
The assembly of one of this entries in clang .s file is:
.long 7
.long .Lfunc_begin2
Within the object one can see:
38: 07 00 00 00 30 00 00 00 add %r0,48
3c: R_BPF_64_NODYLD32 tc
.Lfunc_begin2 is removed from the object, but its value is in-place resolved
with the value 0x30 (offset of .Lfunc_begin2 from tc) as the addend from its
section "tc", in this particular case.
