Re: [PATCH v3 bpf-next 07/17] libbpf: expose BTF-to-C type declaration emitting API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 13, 2019 at 02:32:04PM -0800, Andrii Nakryiko wrote:
> Expose API that allows to emit type declaration and field/variable definition
> (if optional field name is specified) in valid C syntax for any provided BTF
> type. This is going to be used by bpftool when emitting data section layout as
> a struct. As part of making this API useful in a stand-alone fashion, move
> initialization of some of the internal btf_dump state to earlier phase.
> 
> Acked-by: Martin KaFai Lau <kafai@xxxxxx>
> Signed-off-by: Andrii Nakryiko <andriin@xxxxxx>
> ---
>  tools/lib/bpf/btf.h      | 22 ++++++++++++++
>  tools/lib/bpf/btf_dump.c | 62 +++++++++++++++++++++++-----------------
>  tools/lib/bpf/libbpf.map |  1 +
>  3 files changed, 59 insertions(+), 26 deletions(-)
> 
> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> index a114c8ef4f08..1f9625946ead 100644
> --- a/tools/lib/bpf/btf.h
> +++ b/tools/lib/bpf/btf.h
> @@ -126,6 +126,28 @@ LIBBPF_API void btf_dump__free(struct btf_dump *d);
>  
>  LIBBPF_API int btf_dump__dump_type(struct btf_dump *d, __u32 id);
>  
> +struct btf_dump_emit_type_decl_opts {
> +	/* size of this struct, for forward/backward compatiblity */
> +	size_t sz;
> +	/* optional field name for type declaration, e.g.:
> +	 * - struct my_struct <FNAME>
> +	 * - void (*<FNAME>)(int)
> +	 * - char (*<FNAME>)[123]
> +	 */
> +	const char *field_name;
> +	/* extra indentation level (in number of tabs) to emit for multi-line
> +	 * type declarations (e.g., anonymous struct); applies for lines
> +	 * starting from the second one (first line is assumed to have
> +	 * necessary indentation already
> +	 */
> +	int indent_level;
> +};
> +#define btf_dump_emit_type_decl_opts__last_field attach_prog_fd

OPTS_VALID() is missing in btf_dump__emit_type_decl() ?
Otherwise it would have caught above typo.


>  	d->ident_names = hashmap__new(str_hash_fn, str_equal_fn, NULL);
>  	if (IS_ERR(d->ident_names)) {
>  		err = PTR_ERR(d->ident_names);
>  		d->ident_names = NULL;
> -		btf_dump__free(d);
> -		return ERR_PTR(err);
> +		goto err;
> +	}
> +	d->type_states = calloc(1 + btf__get_nr_types(d->btf),
> +				sizeof(d->type_states[0]));
> +	if (!d->type_states) {
> +		err = -ENOMEM;
> +		goto err;
> +	}
> +	d->cached_names = calloc(1 + btf__get_nr_types(d->btf),
> +				 sizeof(d->cached_names[0]));
> +	if (!d->cached_names) {
> +		err = -ENOMEM;
> +		goto err;
>  	}
>  
> +	/* VOID is special */
> +	d->type_states[0].order_state = ORDERED;
> +	d->type_states[0].emit_state = EMITTED;

Not following the logic with 1 + btf__get_nr_types(d->btf) and
above init...
type_states[0] is void. true.
But btf__get_nr_types() includes that type_id=0 == void.
So what this 1+ is for?
I know it's just a move of old code. I just noticed.
Would be great to add a comment.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux