ftrace: show ftrace_bprintk()'s formats

PATCH In review Lai Jiangshan 2 participants 5 messages Dec 31, 2008 – Jan 15, 2009 Tracing

lore

Share & tools

lore

Lai Jiangshan

author

2008-12-31 03:01 UTC #0 lore raw

PATCH 4/5 ftrace: show ftrace_bprintk()'s formats

Impact: let user knows the format

Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.

This formats will help for these condition:
1) User get binary data from core file.(formats are backup before coredump)
2) User splice ring_buffer to a file.
User can use formats for parsing the binary data in userspace.

Signed-off-by Lai Jiangshan <[email protected]>

---
 trace.c         |    8 +++++
 trace.h         |    1
 trace_bprintk.c |   79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 88 insertions(+)

kernel/trace/trace.c +8 -0

index 61c9108..085cc8a 100644
@@ -2944,6 +2944,14 @@ static __init int tracer_init_debugfs(void)
 		pr_warning("Could not create debugfs "
 			   "'trace_marker' entry\n");
 
+#ifdef CONFIG_TRACE_BPRINTK
+	entry = debugfs_create_file("trace_bprintk_formats", 0444, d_tracer,
+				    NULL, &trace_bprintk_fmt_fops);
+	if (!entry)
+		pr_warning("Could not create debugfs "
+			   "'trace_bprintk_formats' entry\n");
+#endif
+
 #ifdef CONFIG_DYNAMIC_FTRACE
 	entry = debugfs_create_file("dyn_ftrace_total_info", 0444, d_tracer,
 				    &ftrace_update_tot_cnt,

kernel/trace/trace.h +1 -0

index 6885d13..c50826d 100644
@@ -128,6 +128,7 @@ struct bprintk_entry {
 	u32 buf[];
 };
 #ifdef CONFIG_TRACE_BPRINTK
+extern struct file_operations trace_bprintk_fmt_fops;
 extern int trace_bprintk_enable;
 #endif

kernel/trace/trace_bprintk.c +79 -0

85 lines not on this page · raw message

Jason Baron

2009-01-13 23:18 UTC #1 lore raw

Quoted 10 lines · Lai Jiangshan

Impact: let user knows the format
Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.
This formats will help for these condition:
1) User get binary data from core file.(formats are backup before coredump)
2) User splice ring_buffer to a file.
User can use formats for parsing the binary data in userspace.

When I 'cat' trace_bprintk_formats on my system the file is empty. This seems to be b/c 'ftrace_bprintk' is not being used in this patchset. It can't be used in patch #5 during marker register b/c the format wouldn't be known at runtime. Thus, as it currently stands this patch, patch 4/5, isn't adding much?

A thought on how this might be resolved would be to have the core marker code pass us its address so this could be recorded in the trace buffer. Then, also add some debug file that displays the markers and maps marker addresses with format strings.

thanks,

-Jason

Lai Jiangshan

author

2009-01-14 02:51 UTC #2 lore raw

Quoted 11 lines · Jason Baron

Quoted 9 lines · Lai Jiangshan
Impact: let user knows the format
Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.
This formats will help for these condition:
1) User get binary data from core file.(formats are backup before coredump)
2) User splice ring_buffer to a file.
User can use formats for parsing the binary data in userspace.

Quoted 5 lines

When I 'cat' trace_bprintk_formats on my system the file is empty. This seems to be b/c 'ftrace_bprintk' is not being used in this patchset. It can't be used in patch #5 during marker register b/c the format wouldn't be known at runtime. Thus, as it currently stands this patch, patch 4/5, isn't adding much?

If you don't use ftrace_bprintk(), the file trace_bprintk_formats is empty. This file record all formats which ftrace_bprintk() uses.

You can use ftrace_bprintk() everywhere as another printk().

Patch #5 enables binary printk for markers, this is another additional tool for tracing markers.

Quoted 6 lines

A thought on how this might be resolved would be to have the core marker code pass us its address so this could be recorded in the trace buffer. Then, also add some debug file that displays the markers and maps marker addresses with format strings.

Patch#5 does it as you said.

Jason Baron

2009-01-14 14:27 UTC #3 lore raw

Quoted 27 lines · Lai Jiangshan

Quoted 11 lines · Jason Baron
Quoted 9 lines · Lai Jiangshan
Impact: let user knows the format
Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.
This formats will help for these condition:
1) User get binary data from core file.(formats are backup before coredump)
2) User splice ring_buffer to a file.
User can use formats for parsing the binary data in userspace.
Quoted 5 lines
When I 'cat' trace_bprintk_formats on my system the file is empty. This seems to be b/c 'ftrace_bprintk' is not being used in this patchset. It can't be used in patch #5 during marker register b/c the format wouldn't be known at runtime. Thus, as it currently stands this patch, patch 4/5, isn't adding much?
If you don't use ftrace_bprintk(), the file trace_bprintk_formats is empty. This file record all formats which ftrace_bprintk() uses.
You can use ftrace_bprintk() everywhere as another printk().
Patch #5 enables binary printk for markers, this is another additional tool for tracing markers.
Quoted 1 line

Quoted 10 lines

Quoted 5 lines
A thought on how this might be resolved would be to have the core marker code pass us its address so this could be recorded in the trace buffer. Then, also add some debug file that displays the markers and maps marker addresses with format strings.
Patch#5 does it as you said.

hmm...i'm still not clear on this. in patch #5 you have:

+static void marker_bprintk_probe(void *probe_private, void *call_private,
+ const char *fmt, va_list *args)
+{
+ struct marker_bprintk_struct *p = probe_private;
+
+ if (p->fmt_state == MARKER_FMT_LACK) {
+ int flen = strlen(fmt);
+ if (p->fmt - p->name + flen < MARKER_NAME_FMT_LEN) {
+ memcpy(p->fmt, fmt, flen + 1);
+ p->fmt_state = MARKER_FMT_OK;
+ } else
+ p->fmt_state = MARKER_FMT_INVALID;
+ }
+
+ if (p->fmt_state == MARKER_FMT_OK)
+ trace_vbprintk(0, p->name, *args);
+}
+

trace_vbprintk first argument is 'ip'. So I don't see how we are associating instruction pointers with each 'ftrace' record? Aren't we just recording each entry with '0' for the 'ip'?

thanks,

-Jason

Lai Jiangshan

author

2009-01-15 10:19 UTC #4 lore raw

Quoted 57 lines · Jason Baron

Quoted 24 lines · Lai Jiangshan
Quoted 10 lines · Jason Baron
Quoted 9 lines · Lai Jiangshan
Impact: let user knows the format
Create a file on <debugfs-dir>/tracing/ to show ftrace_bprintk()'s formats.
This formats will help for these condition:
1) User get binary data from core file.(formats are backup before coredump)
2) User splice ring_buffer to a file.
User can use formats for parsing the binary data in userspace.
Quoted 5 lines
When I 'cat' trace_bprintk_formats on my system the file is empty. This seems to be b/c 'ftrace_bprintk' is not being used in this patchset. It can't be used in patch #5 during marker register b/c the format wouldn't be known at runtime. Thus, as it currently stands this patch, patch 4/5, isn't adding much?
If you don't use ftrace_bprintk(), the file trace_bprintk_formats is empty. This file record all formats which ftrace_bprintk() uses.
You can use ftrace_bprintk() everywhere as another printk().
Patch #5 enables binary printk for markers, this is another additional tool for tracing markers.
Quoted 9 lines
Quoted 5 lines
A thought on how this might be resolved would be to have the core marker code pass us its address so this could be recorded in the trace buffer. Then, also add some debug file that displays the markers and maps marker addresses with format strings.
Patch#5 does it as you said.
hmm...i'm still not clear on this. in patch #5 you have:
(quoted diff) +18 -0
+static void marker_bprintk_probe(void *probe_private, void *call_private,
+		const char *fmt, va_list *args)
+{
+	struct marker_bprintk_struct *p = probe_private;
+
+	if (p->fmt_state == MARKER_FMT_LACK) {
+		int flen = strlen(fmt);
+		if (p->fmt - p->name + flen < MARKER_NAME_FMT_LEN) {
+			memcpy(p->fmt, fmt, flen + 1);
+			p->fmt_state = MARKER_FMT_OK;
+		} else
+			p->fmt_state = MARKER_FMT_INVALID;
+	}
+
+	if (p->fmt_state == MARKER_FMT_OK)
+		trace_vbprintk(0, p->name, *args);
+}
+

Quoted 4 lines

trace_vbprintk first argument is 'ip'. So I don't see how we are associating instruction pointers with each 'ftrace' record? Aren't we just recording each entry with '0' for the 'ip'?

argument 'ip' is used for ftrace_bprintk(), the caller of ftrace_bprintk() will be output in the message.

argument 'ip' is not used when trace markers.
we may can use:
trace_vbprintk(CALLER_ADDR2, p->name, *args);
but this cannot work for !CONFIG_FRAME_POINTER.

I will remove argument 'ip' in next version.(if users need know the call_addr when he use ftrace_bprintk(), just use "%pS":
ftrace_bprintk("%pS: msgfmt example %d, %d", _THIS_IP_, msgarg1, msgarg2);)

Thanks for pointed it out.

Lai.