Netdev List
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Edward Cree <ecree@solarflare.com>,
	Alexei Starovoitov <ast@fb.com>, Martin Lau <kafai@fb.com>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next v2 13/13] tools/bpf: bpftool: add support for jited func types
Date: Wed, 17 Oct 2018 17:28:30 +0000	[thread overview]
Message-ID: <02b9227e-81a2-54fe-9832-dadb30520004@fb.com> (raw)
In-Reply-To: <0b60d21b-dcbf-a0df-7b2c-b0506463af1f@solarflare.com>



On 10/17/18 4:11 AM, Edward Cree wrote:
> On 17/10/18 08:24, Yonghong Song wrote:
>> This patch added support to print function signature
>> if btf func_info is available. Note that ksym
>> now uses function name instead of prog_name as
>> prog_name has a limit of 16 bytes including
>> ending '\0'.
>>
>> The following is a sample output for selftests
>> test_btf with file test_btf_haskv.o:
>>
>>    $ bpftool prog dump jited id 1
>>    int _dummy_tracepoint(struct dummy_tracepoint_args * ):
>>    bpf_prog_b07ccb89267cf242__dummy_tracepoint:
>>       0:   push   %rbp
>>       1:   mov    %rsp,%rbp
>>      ......
>>      3c:   add    $0x28,%rbp
>>      40:   leaveq
>>      41:   retq
>>
>>    int test_long_fname_1(struct dummy_tracepoint_args * ):
>>    bpf_prog_2dcecc18072623fc_test_long_fname_1:
>>       0:   push   %rbp
>>       1:   mov    %rsp,%rbp
>>      ......
>>      3a:   add    $0x28,%rbp
>>      3e:   leaveq
>>      3f:   retq
>>
>>    int test_long_fname_2(struct dummy_tracepoint_args * ):
>>    bpf_prog_89d64e4abf0f0126_test_long_fname_2:
>>       0:   push   %rbp
>>       1:   mov    %rsp,%rbp
>>      ......
>>      80:   add    $0x28,%rbp
>>      84:   leaveq
>>      85:   retq
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>>   tools/bpf/bpftool/btf_dumper.c | 96 ++++++++++++++++++++++++++++++++++
>>   tools/bpf/bpftool/main.h       |  2 +
>>   tools/bpf/bpftool/prog.c       | 54 +++++++++++++++++++
>>   3 files changed, 152 insertions(+)
>>
>> diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
>> index 55bc512a1831..a31df4202335 100644
>> --- a/tools/bpf/bpftool/btf_dumper.c
>> +++ b/tools/bpf/bpftool/btf_dumper.c
>> @@ -249,3 +249,99 @@ int btf_dumper_type(const struct btf_dumper *d, __u32 type_id,
>>   {
>>   	return btf_dumper_do_type(d, type_id, 0, data);
>>   }
>> +
>> +#define BTF_PRINT_STRING(str)						\
>> +	{								\
>> +		pos += snprintf(func_sig + pos, size - pos, str);	\
>> +		if (pos >= size)					\
>> +			return -1;					\
>> +	}
> Usual kernel practice for this sort of macro is to use
>      do { \
>      } while(0)
>   to ensure correct behaviour if the macro is used within another control
>   flow statement, e.g.
>      if (x)
>          BTF_PRINT_STRING(x);
>      else
>          do_something_else();
>   will not compile with the bare braces as the else will be detached.

Thanks for the review! Will change to use the "do while" format
as you suggested.

>> +#define BTF_PRINT_ONE_ARG(fmt, arg)					\
>> +	{								\
>> +		pos += snprintf(func_sig + pos, size - pos, fmt, arg);	\
>> +		if (pos >= size)					\
>> +			return -1;					\
>> +	}
> Any reason for not just using a variadic macro?

No particular reason. I will try to use it in the next revision.

>> +#define BTF_PRINT_TYPE_ONLY(type)					\
>> +	{								\
>> +		pos = __btf_dumper_type_only(btf, type, func_sig,	\
>> +					     pos, size);		\
>> +		if (pos == -1)						\
>> +			return -1;					\
>> +	}
>> +
>> +static int __btf_dumper_type_only(struct btf *btf, __u32 type_id,
>> +				  char *func_sig, int pos, int size)
>> +{
>> +	const struct btf_type *t = btf__type_by_id(btf, type_id);
>> +	const struct btf_array *array;
>> +	int i, vlen;
>> +
>> +	switch (BTF_INFO_KIND(t->info)) {
>> +	case BTF_KIND_INT:
>> +		BTF_PRINT_ONE_ARG("%s ",
>> +				  btf__name_by_offset(btf, t->name_off));
>> +		break;
>> +	case BTF_KIND_STRUCT:
>> +		BTF_PRINT_ONE_ARG("struct %s ",
>> +				  btf__name_by_offset(btf, t->name_off));
>> +		break;
>> +	case BTF_KIND_UNION:
>> +		BTF_PRINT_ONE_ARG("union %s ",
>> +				  btf__name_by_offset(btf, t->name_off));
>> +		break;
>> +	case BTF_KIND_ENUM:
>> +		BTF_PRINT_ONE_ARG("enum %s ",
>> +				  btf__name_by_offset(btf, t->name_off));
>> +		break;
>> +	case BTF_KIND_ARRAY:
>> +		array = (struct btf_array *)(t + 1);
>> +		BTF_PRINT_TYPE_ONLY(array->type);
>> +		BTF_PRINT_ONE_ARG("[%d]", array->nelems);
>> +		break;
>> +	case BTF_KIND_PTR:
>> +		BTF_PRINT_TYPE_ONLY(t->type);
>> +		BTF_PRINT_STRING("* ");
>> +		break;
>> +	case BTF_KIND_UNKN:
>> +	case BTF_KIND_FWD:
>> +	case BTF_KIND_TYPEDEF:
>> +		return -1;
>> +	case BTF_KIND_VOLATILE:
>> +		BTF_PRINT_STRING("volatile ");
>> +		BTF_PRINT_TYPE_ONLY(t->type);
>> +		break;
>> +	case BTF_KIND_CONST:
>> +		BTF_PRINT_STRING("const ");
>> +		BTF_PRINT_TYPE_ONLY(t->type);
>> +		break;
>> +	case BTF_KIND_RESTRICT:
>> +		BTF_PRINT_STRING("restrict ");
>> +		BTF_PRINT_TYPE_ONLY(t->type);
>> +		break;
>> +	case BTF_KIND_FUNC:
>> +	case BTF_KIND_FUNC_PROTO:
>> +		BTF_PRINT_TYPE_ONLY(t->type);
>> +		BTF_PRINT_ONE_ARG("%s(", btf__name_by_offset(btf, t->name_off));
>> +		vlen = BTF_INFO_VLEN(t->info);
>> +		for (i = 0; i < vlen; i++) {
>> +			__u32 arg_type = ((__u32 *)(t + 1))[i];
>> +
>> +			BTF_PRINT_TYPE_ONLY(arg_type);
>> +			if (i != (vlen - 1))
>> +				BTF_PRINT_STRING(", ");
>> +		}
> In this kind of loop I find it cleaner to print the comma before the item;
>   that way the test becomes i != 0.  Thus:
>      for (i = 0; i < vlen; i++) {
>          __u32 arg_type = ((__u32 *)(t + 1))[i];
> 
>          if (i)
>              BTF_PRINT_STRING(", ");
>          BTF_PRINT_TYPE_ONLY(arg_type);
>      }

Good suggestion. Will make change in the next revision.

> 
> -Ed
> 

      reply	other threads:[~2018-10-18  1:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17  7:23 [PATCH bpf-next v2 10/13] tools/bpf: do not use pahole if clang/llvm can generate BTF sections Yonghong Song
2018-10-17  7:23 ` [PATCH bpf-next v2 11/13] tools/bpf: refactor to implement btf_get_from_id() in lib/bpf Yonghong Song
2018-10-17  7:23 ` [PATCH bpf-next v2 12/13] tools/bpf: enhance test_btf file testing to test func info Yonghong Song
2018-10-17  7:24 ` [PATCH bpf-next v2 13/13] tools/bpf: bpftool: add support for jited func types Yonghong Song
2018-10-17 11:11   ` Edward Cree
2018-10-17 17:28     ` Yonghong Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02b9227e-81a2-54fe-9832-dadb30520004@fb.com \
    --to=yhs@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=ecree@solarflare.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox