On 10/12/2018 08:54 PM, Yonghong Song wrote:
> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
> support to the type section. BTF_KIND_FUNC_PROTO is used
> to specify the type of a function pointer. With this,
> BTF has a complete set of C types (except float).
> 
> BTF_KIND_FUNC is used to specify the signature of a
> defined subprogram. BTF_KIND_FUNC_PROTO can be referenced
> by another type, e.g., a pointer type, and BTF_KIND_FUNC
> type cannot be referenced by another type.
> 
> For both BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO types,
> the func return type is in t->type (where t is a
> "struct btf_type" object). The func args are an array of
> u32s immediately following object "t".
> 
> As a concrete example, for the C program below,
>   $ cat test.c
>   int foo(int (*bar)(int)) { return bar(5); }
> with latest llvm trunk built with Debug mode, we have
>   $ clang -target bpf -g -O2 -mllvm -debug-only=btf -c test.c
>   Type Table:
>   [1] FUNC name_off=1 info=0x0c000001 size/type=2
>           param_type=3
>   [2] INT name_off=11 info=0x01000000 size/type=4
>           desc=0x01000020
>   [3] PTR name_off=0 info=0x02000000 size/type=4
>   [4] FUNC_PROTO name_off=0 info=0x0d000001 size/type=2
>           param_type=2
> 
>   String Table:
>   0 :
>   1 : foo
>   5 : .text
>   11 : int
>   15 : test.c
>   22 : int foo(int (*bar)(int)) { return bar(5); }
> 
>   FuncInfo Table:
>   sec_name_off=5
>           insn_offset=<Omitted> type_id=1
> 
>   ...
> 
> (Eventually we shall have bpftool to dump btf information
>  like the above.)
> 
> Function "foo" has a FUNC type (type_id = 1).
> The parameter of "foo" has type_id 3 which is PTR->FUNC_PROTO,
> where FUNC_PROTO refers to function pointer "bar".

Should also "bar" be part of the string table (at least at some point in 
future)?
Iow, if verifier hints to an issue in the program when it would for example walk
pointers and rewrite ctx access, then it could dump the var name along with it.
It might be useful as well in combination with 22 from str table, when 
annotating
the source. We might need support for variadic functions, though. How is LLVM
handling the latter with the recent BTF support?

> In FuncInfo Table, for section .text, the function,
> with to-be-determined offset (marked as <Omitted>),
> has type_id=1 which refers to a FUNC type.
> This way, the function signature is
> available to both kernel and user space.
> Here, the insn offset is not available during the dump time
> as relocation is resolved pretty late in the compilation process.
> 
> Signed-off-by: Martin KaFai Lau <ka...@fb.com>
> Signed-off-by: Yonghong Song <y...@fb.com>

Reply via email to