perf/ftrace: Introduce hexadecimal type casting

Add x8/x16/x32/x64 for hexadecimal type casting to kprobe/uprobe event tracer.

These type casts can be used for integer arguments for explicitly showing them in hexadecimal digits in formatted text.

Signed-off-by Masami Hiramatsu <[email protected]>

Add README entries for kprobe-events and uprobe-events. This allows user to check what options can be acceptable for running kernel.
E.g. perf tools can choose correct types for the kernel.

Signed-off-by Masami Hiramatsu <[email protected]>

---

Add a checking routine what types are supported by the running kernel by finding the pattern in <debugfs>/tracing/README.

Signed-off-by Masami Hiramatsu <[email protected]>

---
 tools/perf/util/probe-file.c   |   57 ++++++++++++++++++++++++++++++++++++++++
 tools/perf/util/probe-file.h   |   10 +++++++
 tools/perf/util/probe-finder.c |    1 +
 3 files changed, 68 insertions(+)

tools/perf/util/probe-file.c +57 -0

index 9aed9c3..552e56b 100644
@@ -855,3 +855,60 @@ int probe_cache__show_all_caches(struct strfilter *filter)
 
 	return 0;
 }
+
+static struct {
+	const char *pattern;
+	bool	avail;
+	bool	checked;
+} probe_type_table[] = {
+#define DEFINE_TYPE(idx, pat, def_avail)	\
+	[idx] = {.pattern = pat, .avail = (def_avail)}
+	DEFINE_TYPE(PROBE_TYPE_U, "* u8/16/32/64,*", true),
+	DEFINE_TYPE(PROBE_TYPE_S, "* s8/16/32/64,*", true),
+	DEFINE_TYPE(PROBE_TYPE_X, "* x8/16/32/64,*", false),
+	DEFINE_TYPE(PROBE_TYPE_STRING, "* string,*", true),
+	DEFINE_TYPE(PROBE_TYPE_BITFIELD,
+		    "* b<bit-width>@<bit-offset>/<container-size>", true),
+};
+
+bool probe_type_is_available(enum probe_type type)
+{
+	FILE *fp;
+	char *buf = NULL;
+	size_t len = 0;
+	bool target_line = false;
+	bool ret = probe_type_table[type].avail;
+
+	if (type < 0 || type >= PROBE_TYPE_END)
+		return false;
+	/* We don't have to check the type which supported by default */
+	if (ret || probe_type_table[type].checked)
+		return ret;
+
+	if (asprintf(&buf, "%s/README", tracing_path) < 0)
+		return ret;
+
+	fp = fopen(buf, "r");
+	if (!fp)
+		goto end;
+
+	zfree(&buf);
+	while (getline(&buf, &len, fp) > 0 && !ret) {
+		if (!target_line) {
+			target_line = !!strstr(buf, " type: ");
+			if (!target_line)
+				continue;
+		} else if (strstr(buf, "\t          ") != buf)
+			break;
+		ret = strglobmatch(buf, probe_type_table[type].pattern);
+	}
+	/* Cache the result */
+	probe_type_table[type].checked = true;
+	probe_type_table[type].avail = ret;
+
+	fclose(fp);
+end:
+	free(buf);
+
+	return ret;
+}

tools/perf/util/probe-file.h +10 -0

index 9577b5c..eba44c3 100644
@@ -19,6 +19,15 @@ struct probe_cache {
 	struct list_head entries;
 };
 
+enum probe_type {
+	PROBE_TYPE_U = 0,
+	PROBE_TYPE_S,
+	PROBE_TYPE_X,
+	PROBE_TYPE_STRING,
+	PROBE_TYPE_BITFIELD,
+	PROBE_TYPE_END,
+};
+
 #define PF_FL_UPROBE	1
 #define PF_FL_RW	2
 #define for_each_probe_cache_entry(entry, pcache) \

@@ -54,6 +63,7 @@ struct probe_cache_entry *probe_cache__find(struct probe_cache *pcache,
 struct probe_cache_entry *probe_cache__find_by_name(struct probe_cache *pcache,
 					const char *group, const char *event);
 int probe_cache__show_all_caches(struct strfilter *filter);
+bool probe_type_is_available(enum probe_type type);
 #else	/* ! HAVE_LIBELF_SUPPORT */
 static inline struct probe_cache *probe_cache__new(const char *tgt __maybe_unused)
 {

tools/perf/util/probe-finder.c +1 -0

index 5c290c6..24dbe23 100644
@@ -39,6 +39,7 @@
 #include "util.h"
 #include "symbol.h"
 #include "probe-finder.h"
+#include "probe-file.h"
 
 /* Kprobe tracer basic type is up to u64 */
 #define MAX_BASIC_TYPE_BITS	64

Change kprobe/uprobe-tracer to show the arguments type-casted with u8/u16/u32/u64 in decimal digits instead of hexadecimal.

To minimize compatibility issue, the arguments without type casting are typed by x64 (or x32 for 32bit arch) by default.

Note: all arguments set by old perf probe without types are shown in decimal by default.

Signed-off-by Masami Hiramatsu <[email protected]>

---

Hi Arnaldo and Steven,

Here is an RFC series of hexadecimal type casting and changing default type casting of perf and ftrace.

I've introduced x8,x16,x32,x64 according to previous discussion on LKML.
https://lkml.org/lkml/2016/8/10/339

This series includes not only adding hexadecimal types (x8,x16,x32,x64), but also checking it is supported by running kernel and keeping the backward compativility.

[1/6] Add hexadecimal type casting, but does not touch
existing types like 'u8'.
[2/6] Show the supported types on README of ftrace so
that user application (e.g. perf) can check that.
[3/6] Add a type availability check to perf-probe. [4/6] Add hexadecimal prefix support to perf-probe if
it is supported by the kernel.
[5/6] Change the perf-probe default type casting for
unsigned type to hexadecimal (for backward compatibility)
[6/6] Change ftrace's 'uNN' to show value in decimal
and use 'xNN' by default (for backward compatibility)

This way, we can also add "octal" type, pointer type, and "character" type etc. and perf can check whether the kernel supports it or not. :)

Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:

Quoted 25 lines

Hi Arnaldo and Steven,

Here is an RFC series of hexadecimal type casting and changing default type casting of perf and ftrace.

I've introduced x8,x16,x32,x64 according to previous discussion on LKML.
https://lkml.org/lkml/2016/8/10/339

This series includes not only adding hexadecimal types (x8,x16,x32,x64), but also checking it is supported by running kernel and keeping the backward compativility.

[1/6] Add hexadecimal type casting, but does not touch
existing types like 'u8'.
[2/6] Show the supported types on README of ftrace so
that user application (e.g. perf) can check that.
[3/6] Add a type availability check to perf-probe. [4/6] Add hexadecimal prefix support to perf-probe if
it is supported by the kernel.
[5/6] Change the perf-probe default type casting for
unsigned type to hexadecimal (for backward compatibility)
[6/6] Change ftrace's 'uNN' to show value in decimal
and use 'xNN' by default (for backward compatibility)

Quoted 3 lines

This way, we can also add "octal" type, pointer type, and "character" type etc. and perf can check whether the kernel supports it or not. :)

But this requires a kernel update... If we do it all in the tooling side, no kernel changes are required _and_ newer tools will work with older kernels, as this is just a formatting issue, the value is there and from its format one can infer its value, it is not even necessary to look at its "type".

I understand this is necessary for ftrace, because the pretty printer is in the kernel, but I don't see why we would prevent tooling from doing this pretty printing work and make it support any kernel.

I.e. no need at all for checking if the kernel supports anything, just pretty print it.

Quoted 36 lines · On Thu, 18 Aug 2016 11:14:42 -0300 Arnaldo Carvalho de Melo <[email protected]>…

Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:

Quoted 25 lines

Hi Arnaldo and Steven,

Here is an RFC series of hexadecimal type casting and changing default type casting of perf and ftrace.

I've introduced x8,x16,x32,x64 according to previous discussion on LKML.
https://lkml.org/lkml/2016/8/10/339

This series includes not only adding hexadecimal types (x8,x16,x32,x64), but also checking it is supported by running kernel and keeping the backward compativility.

[1/6] Add hexadecimal type casting, but does not touch
existing types like 'u8'.
[2/6] Show the supported types on README of ftrace so
that user application (e.g. perf) can check that.
[3/6] Add a type availability check to perf-probe. [4/6] Add hexadecimal prefix support to perf-probe if
it is supported by the kernel.
[5/6] Change the perf-probe default type casting for
unsigned type to hexadecimal (for backward compatibility)
[6/6] Change ftrace's 'uNN' to show value in decimal
and use 'xNN' by default (for backward compatibility)

Quoted 3 lines

This way, we can also add "octal" type, pointer type, and "character" type etc. and perf can check whether the kernel supports it or not. :)

But this requires a kernel update... If we do it all in the tooling side, no kernel changes are required _and_ newer tools will work with older kernels, as this is just a formatting issue, the value is there and from its format one can infer its value, it is not even necessary to look at its "type".

Quoted 6 lines

I understand this is necessary for ftrace, because the pretty printer is in the kernel, but I don't see why we would prevent tooling from doing this pretty printing work and make it support any kernel.

I.e. no need at all for checking if the kernel supports anything, just pretty print it.

That's should be handled by libtraceevent. And if you need just a pretty printing, you can do it in python/perl script via perf-script. Anyway, to see the event parameters via perf tools, we have to use perf-script with/without scripts. As you know, perf-script without scripts, the output format depends on libtraceevent. And it seems that the libtraceevent output depends on ftrace event "format" file.

And also as you can see in Naohiro's report　( https://lkml.org/lkml/2016/8/5/191 ) he was using perf-probe with ftrace trace_pipe interface, which was my expected usecase. In that case we have to change ftrace side to support various pretty printing.

IOW, perf only has very strong pretty printing interface - script based output - for trace event arguments. For lighter use cases, ftrace provide the print format.

So, I think this is a better meeting point, wouldn't you?

Em Fri, Aug 19, 2016 at 01:01:43AM +0900, Masami Hiramatsu escreveu:

Quoted 53 lines

Quoted 36 lines · On Thu, 18 Aug 2016 11:14:42 -0300 Arnaldo Carvalho de Melo <[email protected]>…

Em Thu, Aug 18, 2016 at 05:57:32PM +0900, Masami Hiramatsu escreveu:

Quoted 25 lines

Hi Arnaldo and Steven,

Here is an RFC series of hexadecimal type casting and changing default type casting of perf and ftrace.

I've introduced x8,x16,x32,x64 according to previous discussion on LKML.
https://lkml.org/lkml/2016/8/10/339

This series includes not only adding hexadecimal types (x8,x16,x32,x64), but also checking it is supported by running kernel and keeping the backward compativility.

[1/6] Add hexadecimal type casting, but does not touch
existing types like 'u8'.
[2/6] Show the supported types on README of ftrace so
that user application (e.g. perf) can check that.
[3/6] Add a type availability check to perf-probe. [4/6] Add hexadecimal prefix support to perf-probe if
it is supported by the kernel.
[5/6] Change the perf-probe default type casting for
unsigned type to hexadecimal (for backward compatibility)
[6/6] Change ftrace's 'uNN' to show value in decimal
and use 'xNN' by default (for backward compatibility)

Quoted 3 lines

This way, we can also add "octal" type, pointer type, and "character" type etc. and perf can check whether the kernel supports it or not. :)

But this requires a kernel update... If we do it all in the tooling side, no kernel changes are required _and_ newer tools will work with older kernels, as this is just a formatting issue, the value is there and from its format one can infer its value, it is not even necessary to look at its "type".

Quoted 6 lines

I understand this is necessary for ftrace, because the pretty printer is in the kernel, but I don't see why we would prevent tooling from doing this pretty printing work and make it support any kernel.

I.e. no need at all for checking if the kernel supports anything, just pretty print it.

That's should be handled by libtraceevent. And if you need just a pretty printing, you can do it in python/perl script via perf-script. Anyway, to see the event parameters via perf tools, we have to use perf-script with/without scripts. As you know, perf-script without scripts, the output format depends on libtraceevent. And it seems that the libtraceevent output depends on ftrace event "format" file.

Quoted 4 lines

And also as you can see in Naohiro's report　( https://lkml.org/lkml/2016/8/5/191 ) he was using perf-probe with ftrace trace_pipe interface, which was my expected usecase. In that case we have to change ftrace side to support various pretty printing.

Sure, if one wants to have pretty printing via trace_pipe, then a kernel reboot is needed, I'm talking about those who don't want to or can't reboot their machines :-)

But anyway, your patches allow seeing those events in decimal for people that can reboot their machine when that wasn't possible without extra scripting via perl/python, a clear advance!

It remains to be coded a way to achieve the same result without requiring a kernel reboot, i.e. a tooling only change.

Hi Arnaldo and Steven,

Quoted 2 lines · On Thu, 18 Aug 2016 17:57:32 +0900 Masami Hiramatsu <[email protected]> wrote:

Hi Arnaldo and Steven,

Arnaldo,

I acked all the patches with ftrace in the subject. You can take the series through your tree.