Skip to contentSkip to conversation

perf: Introduce bts sub commands

PATCH Superseded Akihiro Nagai 3 participants 17 messages Dec 21, 2010 – Dec 24, 2010 perf events

v2 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v2 cover perf: Introduce bts sub commands

Hi,

This patch series provides the commands 'perf bts record' and 'perf bts trace' version 2. These commands can record and analyze BTS (Branch Trace Store) log. And, provide the interface to use BTS log for application developers.

BTS is a facility of Intel x86 processors, which can record the address of 'branch to/from' on every branch/jump instruction and interrupt. This facility is very useful for developers to test their software. For example, coverage test, execution path analysis, dynamic step count ...etc. Also, those tools can have a very big advantage that they don't require any changes of the target executable binaries.

But, there are few applications using BTS. Reasons I guess are ...
- Few people know what BTS is.
- Few people know how to use BTS on Linux box.
- It's hard to analyze the BTS log because it includes just a series of addresses.

So, I want to provide a user-friendly interface to BTS for application developers.

About new sub commands
========================
'perf bts record' provides the easy way to record bts log. Usage is 'perf bts record <command>'. This command is just an alias to 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and more intuitive.

'perf bts trace' can parse and analyze recorded bts log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Example: 'perf bts trace'
function+offset

irq_return+0x0  => _start+0x0
irq_return+0x0  => _start+0x0
_start+0x3      => _dl_start+0x0
irq_return+0x0  => _dl_start+0x0
irq_return+0x0  => _dl_start+0x26
irq_return+0x0  => _dl_start+0x2d
_dl_start+0x71  => _dl_start+0x93
_dl_start+0x97  => _dl_start+0x78

...

This is the default behavior of 'perf bts trace'. It prints function+offset.

Example2: 'perf bts -cas trace'
command address function+offset

ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
ls      0x0000003806200b23 _start+0x3      => ls   0x0000003806204910 _dl_start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204910 _dl_start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204936 _dl_start+0x26
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x000000380620493d _dl_start+0x2d
ls      0x0000003806204981 _dl_start+0x71  => ls   0x00000038062049a3 _dl_start+0x93
ls      0x00000038062049a7 _dl_start+0x97  => ls   0x0000003806204988 _dl_start+0x78

...

In the future, I'd like to make this more informative. For example
- Show source file path
- Show line number
- Show inlined function name
- Draw call graph
- Browse source code and coloring
- Make bts record fast
and more!

Changes in V2:
- Update to the latest -tip tree
- add bts explanation to the subcommand list
- remove the patch already merged (add OPT_CALLBACK_DEFAULT_NOOPT)
- add comments
- add new function to the todo list

Thanks,

---

Akihiro Nagai (6):
perf bts trace: add print all option
perf bts trace: print function+offset
perf bts trace: print file path of the executed elf perf bts trace: print pid and command
perf bts: Introduce new sub command 'perf bts trace'
perf: Introduce perf sub command 'bts record'

 tools/perf/Documentation/perf-bts.txt |   53 ++++++
 tools/perf/Makefile                   |    1 
 tools/perf/builtin-bts.c              |  301 +++++++++++++++++++++++++++++++++
 tools/perf/builtin.h                  |    1 
 tools/perf/command-list.txt           |    1 
 tools/perf/perf.c                     |    1 
 6 files changed, 358 insertions(+), 0 deletions(-)
 create mode 100644 tools/perf/Documentation/perf-bts.txt
 create mode 100644 tools/perf/builtin-bts.c
Signature · 1 line
Akihiro Nagai ([email protected])
#1 lore raw

PATCH v2 1/6 perf: Introduce perf sub command 'bts record'

Introduce the easy way to record bts log, 'perf bts record'. This command can record the bts log while specified command is executing, and save to the file "perf.data"

Usage:
perf bts record <tracee command>

Example:

  # perf bts record ls -l
    (ls -l outputs)
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.007 MB perf.data (~320 samples) ]
  # ls
    perf.data

Changes in V2:
- Update to the latest -tip tree
- add bts explanation to the subcommand list

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |   24 +++++++++++++
 tools/perf/Makefile                   |    1 +
 tools/perf/builtin-bts.c              |   62 +++++++++++++++++++++++++++++++++
 tools/perf/builtin.h                  |    1 +
 tools/perf/command-list.txt           |    1 +
 tools/perf/perf.c                     |    1 +
 6 files changed, 90 insertions(+), 0 deletions(-)
 create mode 100644 tools/perf/Documentation/perf-bts.txt
 create mode 100644 tools/perf/builtin-bts.c
tools/perf/Documentation/perf-bts.txt new file +24 -0
new file mode 100644
index 0000000..55a2fe6
@@ -0,0 +1,24 @@
+perf-bts(1)
+==============
+
+NAME
+----
+perf-bts - Record branch-trace-store log
+
+SYNOPSIS
+--------
+[verse]
+'perf bts' record <command>
+
+DESCRIPTION
+-----------
+This command can record branch-trace-store log.
+Branch-trace-store is a facility of processors. It can record
+address of branch to/from on every branch instruction and interrupt.
+
+'perf bts record <command>' records branch-trace-store log while specified
+command is executing. And, save to the file "perf.data".
+
+SEE ALSO
+--------
+linkperf:perf-record[1]
tools/perf/Makefile +1 -0
index ac6692c..cd3a8df 100644
@@ -502,6 +502,7 @@ BUILTIN_OBJS += $(OUTPUT)builtin-lock.o
 BUILTIN_OBJS += $(OUTPUT)builtin-kvm.o
 BUILTIN_OBJS += $(OUTPUT)builtin-test.o
 BUILTIN_OBJS += $(OUTPUT)builtin-inject.o
+BUILTIN_OBJS += $(OUTPUT)builtin-bts.o
 
 PERFLIBS = $(LIB_FILE)
 
tools/perf/builtin-bts.c new file +62 -0

62 lines not on this page · raw message

tools/perf/builtin.h +1 -0
index c7798c7..11ed837 100644
@@ -35,5 +35,6 @@ extern int cmd_lock(int argc, const char **argv, const char *prefix);
 extern int cmd_kvm(int argc, const char **argv, const char *prefix);
 extern int cmd_test(int argc, const char **argv, const char *prefix);
 extern int cmd_inject(int argc, const char **argv, const char *prefix);
+extern int cmd_bts(int argc, const char **argv, const char *prefix);
 
 #endif
tools/perf/command-list.txt +1 -0
index 16b5088..956acea 100644
@@ -22,3 +22,4 @@ perf-kmem			mainporcelain common
 perf-lock			mainporcelain common
 perf-kvm			mainporcelain common
 perf-test			mainporcelain common
+perf-bts			mainporcelain common
tools/perf/perf.c +1 -0
index 595d0f4..4f4a98a 100644
@@ -331,6 +331,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "kvm",	cmd_kvm,	0 },
 		{ "test",	cmd_test,	0 },
 		{ "inject",	cmd_inject,	0 },
+		{ "bts",	cmd_bts,	0 },
 	};
 	unsigned int i;
 	static const char ext[] = STRIP_EXTENSION;
#2 lore raw

PATCH v2 2/6 perf bts: Introduce new sub command 'perf bts trace'

In reply to Akihiro Nagai

Introduce new sub command 'perf bts trace'. This command can parse and print bts log recorded by 'perf bts record'.

Usage:
- First, record the bts log 'perf bts record <command>'
- Second, parse and print bts log 'perf bts trace'

Output:
0xffffffff8146fe0e => 0x0000003806200b20
0x0000003806200b23 => 0x0000003806204910
0xffffffff8146fe0e => 0x0000003806204910
0xffffffff8146fe0e => 0x0000003806204936
0xffffffff8146fe0e => 0x000000380620493d
0x0000003806204981 => 0x00000038062049a3
0x00000038062049a7 => 0x0000003806204988
...

Changes in V2:
- Update to the latest -tip tree

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |   14 ++++++--
 tools/perf/builtin-bts.c              |   56 +++++++++++++++++++++++++++++++--
 2 files changed, 64 insertions(+), 6 deletions(-)
tools/perf/Documentation/perf-bts.txt +11 -3
index 55a2fe6..5920dcc 100644
@@ -3,22 +3,30 @@ perf-bts(1)
 
 NAME
 ----
-perf-bts - Record branch-trace-store log
+perf-bts - Record and print branch-trace-store log
 
 SYNOPSIS
 --------
 [verse]
-'perf bts' record <command>
+'perf bts' [<options>] {record|trace}
 
 DESCRIPTION
 -----------
-This command can record branch-trace-store log.
+This command can record and print branch-trace-store log.
 Branch-trace-store is a facility of processors. It can record
 address of branch to/from on every branch instruction and interrupt.
 
 'perf bts record <command>' records branch-trace-store log while specified
 command is executing. And, save to the file "perf.data".
 
+'perf bts trace' parses recorded branch-trace-store log and prints it.
+
+OPTIONS
+-------
+-i::
+--input=::
+        Specify input file name to analyze.
+
 SEE ALSO
 --------
 linkperf:perf-record[1]
tools/perf/builtin-bts.c +53 -3

80 lines not on this page · raw message

#3 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 110 lines · Akihiro Nagai

Introduce new sub command 'perf bts trace'. This command can parse and print bts log recorded by 'perf bts record'.

Usage:
- First, record the bts log 'perf bts record <command>'
- Second, parse and print bts log 'perf bts trace'

Output:
0xffffffff8146fe0e => 0x0000003806200b20
0x0000003806200b23 => 0x0000003806204910
0xffffffff8146fe0e => 0x0000003806204910
0xffffffff8146fe0e => 0x0000003806204936
0xffffffff8146fe0e => 0x000000380620493d
0x0000003806204981 => 0x00000038062049a3
0x00000038062049a7 => 0x0000003806204988
...

Changes in V2:
- Update to the latest -tip tree

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |   14 ++++++--
 tools/perf/builtin-bts.c              |   56 +++++++++++++++++++++++++++++++--
 2 files changed, 64 insertions(+), 6 deletions(-)
tools/perf/Documentation/perf-bts.txt +11 -3
index 55a2fe6..5920dcc 100644
@@ -3,22 +3,30 @@ perf-bts(1)
 
 NAME
 ----
-perf-bts - Record branch-trace-store log
+perf-bts - Record and print branch-trace-store log
 
 SYNOPSIS
 --------
 [verse]
-'perf bts' record <command>
+'perf bts' [<options>] {record|trace}
 
 DESCRIPTION
 -----------
-This command can record branch-trace-store log.
+This command can record and print branch-trace-store log.
 Branch-trace-store is a facility of processors. It can record
 address of branch to/from on every branch instruction and interrupt.
 
 'perf bts record <command>' records branch-trace-store log while specified
 command is executing. And, save to the file "perf.data".
 
+'perf bts trace' parses recorded branch-trace-store log and prints it.
+
+OPTIONS
+-------
+-i::
+--input=::
+        Specify input file name to analyze.
+
 SEE ALSO
 --------
 linkperf:perf-record[1]
tools/perf/builtin-bts.c +18 -3
index 587cfad..0d546d8 100644
@@ -1,10 +1,26 @@
 #include "builtin.h"
 #include "perf.h"
 #include "util/parse-options.h"
+#include "util/session.h"
+#include "util/cache.h"
+#include "util/trace-event.h"
+#include <inttypes.h>
+
+/* format string of specifying min width to print address */
+#if __WORDSIZE == 32
+#define FMT_ADDR_WIDTH	"10"		/* length of "0x" + 32bit address */
+#else
+#define FMT_ADDR_WIDTH	"18"		/* length of "0x" + 64bit address */
+#endif
+/* format string to print address */
+#define FMT_ADDR	"%#0" FMT_ADDR_WIDTH "llx"
+
+/* default input file name to analyze */
+static const char *input_name = "perf.data";
 
 static const char * const bts_usage[] = {
-	"perf bts record <command>",
-	NULL,
+	"perf bts [<options>] {record|trace}",
+	NULL
 };
 
 /* arguments to call 'perf record' */
@@ -16,11 +32,41 @@ static const char * const record_args[] = {
 	"-d",
 };
 
-/* dummy struct option to call parse_options() */

tools/perf/builtin-bts.c static const char * const record_args[] = { · line 44

Quoted 10 lines
tools/perf/builtin-bts.c +6 -0
 static const struct option bts_options[] = {
+	OPT_STRING('i', "input", &input_name, "file", "input file name"),
 	OPT_END()
 };
 
+static int process_sample_event(event_t *event __unused,
+	struct sample_data *sample, struct perf_session *session __unused)
+{
+	/* sample->ip is 'from address', sample->addr is 'to address' */
+	printf(FMT_ADDR " => " FMT_ADDR "\n", sample->ip, sample->addr);

It seems this unconditionally prints out the event, but a sample event can be about anything. If you recorded only branches it's fine, but if there were other events this will mess up.

Well, when you launch the tool you can iterate into the session->header.attr and check if there is something else than a branch perf event. And then emit a warning if so.

That doesn't solve the problem but the user will know there is one.

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

Then you can find the PERF_SAMPLE_ID that matches your event. If we record that in the perf headers we can retrieve which events id are the branch ones.

But well, that's a secondary problem for now.

maintainer
#4 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 2 lines · Frederic Weisbecker

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

That would grow the data size for little gain, as long as you only record BTS data into the buffer the current bits should work fine.

#5 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 6 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

That would grow the data size for little gain, as long as you only record BTS data into the buffer the current bits should work fine.

Indeed.

In the longer term though, I think we need a specific branch set record.

Currently for every branch pair we create a new event with all the headers, so the pid, time, etc... are all repeated for every entries.

We rather need a single record everytime we flush the bts buffer to the perf buffer.

maintainer
#6 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 10 lines · Frederic Weisbecker
Quoted 6 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

That would grow the data size for little gain, as long as you only record BTS data into the buffer the current bits should work fine.

Indeed.

Quoted 7 lines

In the longer term though, I think we need a specific branch set record.

Currently for every branch pair we create a new event with all the headers, so the pid, time, etc... are all repeated for every entries.

We rather need a single record everytime we flush the bts buffer to the perf buffer.

We also don't want arch specific data interfaces, so we need to iterate the bts buffer and copy the stuff anyway, and if you don't want the time and pid bits don't set those PERF_SAMPLE bits.

#7 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 16 lines · Peter Zijlstra
Quoted 15 lines · Frederic Weisbecker
Quoted 6 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

That would grow the data size for little gain, as long as you only record BTS data into the buffer the current bits should work fine.

Indeed.

In the longer term though, I think we need a specific branch set record.

Currently for every branch pair we create a new event with all the headers, so the pid, time, etc... are all repeated for every entries.

Quoted 6 lines
Quoted 2 lines

We rather need a single record everytime we flush the bts buffer to the perf buffer.

We also don't want arch specific data interfaces, so we need to iterate the bts buffer and copy the stuff anyway, and if you don't want the time and pid bits don't set those PERF_SAMPLE bits.

But we may actually want the time and pid bits.

This could be a PERF_SAMPLE_RAW may be?

maintainer
#8 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 1 line · Frederic Weisbecker

This could be a PERF_SAMPLE_RAW may be?

Well clearly not ;-)

But maybe we can do something like: PERF_RECORD_SAMPLES (note the plural):

struct {
	struct perf_event_header		header;

	u64					nr;
	u32					common_type;
	u32					data_type;

	struct perf_sample			common;
	struct perf_sample			data[nr];
}

Where struct perf_sample is PERF_RECORD_SAMPLE without the perf_event_header bit.

Where we can split the many samples into a piece that is the same for all perf_samples::common, where the content specified by the PERF_SAMPLE_ bits from ::common_type, and the the rest lives in data[] specified by the PERF_SAMPLE_ bits from ::data_type.

#9 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 20 lines · Peter Zijlstra
Quoted 1 line · Frederic Weisbecker

This could be a PERF_SAMPLE_RAW may be?

Well clearly not ;-)

But maybe we can do something like: PERF_RECORD_SAMPLES (note the plural):

struct {
	struct perf_event_header		header;

	u64					nr;
	u32					common_type;
	u32					data_type;

	struct perf_sample			common;
	struct perf_sample			data[nr];
}
Quoted 7 lines

Where struct perf_sample is PERF_RECORD_SAMPLE without the perf_event_header bit.

Where we can split the many samples into a piece that is the same for all perf_samples::common, where the content specified by the PERF_SAMPLE_ bits from ::common_type, and the the rest lives in data[] specified by the PERF_SAMPLE_ bits from ::data_type.

Well, yeah but that involves some new corner cases in both the kernel and userspace.

What about a generic branch record like:

struct branch {
	u64 nr;
	struct {
		u64 from;
		u64 to;
	}[nr]
}

This is going to be useful also when one day we'll support the function tracer, lbr and so...

maintainer
#10 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

Quoted 24 lines · Frederic Weisbecker
Quoted 23 lines · Peter Zijlstra
Quoted 1 line · Frederic Weisbecker

This could be a PERF_SAMPLE_RAW may be?

Well clearly not ;-)

But maybe we can do something like: PERF_RECORD_SAMPLES (note the plural):

struct {
	struct perf_event_header		header;

	u64					nr;
	u32					common_type;
	u32					data_type;

	struct perf_sample			common;
	struct perf_sample			data[nr];
}

Where struct perf_sample is PERF_RECORD_SAMPLE without the perf_event_header bit.

Quoted 8 lines
Quoted 4 lines

Where we can split the many samples into a piece that is the same for all perf_samples::common, where the content specified by the PERF_SAMPLE_ bits from ::common_type, and the the rest lives in data[] specified by the PERF_SAMPLE_ bits from ::data_type.

Well, yeah but that involves some new corner cases in both the kernel and userspace.

Hardly.

Quoted 10 lines

What about a generic branch record like:

struct branch {
	u64 nr;
	struct {
		u64 from;
		u64 to;
	}[nr]
}
Quoted 2 lines

This is going to be useful also when one day we'll support the function tracer, lbr and so...

No, since that suffers the exact same problem you currently have, no TIME,TID,etc.. Nor is it quite usable for LBR since there is no clear means of associating it with a previous PERF_RECORD_SAMPLE.

(LBR really is quite different from BTS)

#11 lore raw

Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'

In reply to Frederic Weisbecker

(2010/12/22 3:31), Frederic Weisbecker wrote:
[...]

Quoted 9 lines

tools/perf/builtin-bts.c static const char * const record_args[] = { · line 44

Quoted 5 lines
tools/perf/builtin-bts.c +5 -0
+static int process_sample_event(event_t *event __unused,
+	struct sample_data *sample, struct perf_session *session __unused)
+{
+	/* sample->ip is 'from address', sample->addr is 'to address' */
+	printf(FMT_ADDR " =>  " FMT_ADDR "\n", sample->ip, sample->addr);

It seems this unconditionally prints out the event, but a sample event can be about anything. If you recorded only branches it's fine, but if there were other events this will mess up.

Exactly.
I'll add a check code of PERF_SAMPLE_ID there.

And, I found the problem that perf cannot handle the data including multiple event types. I executed following command to make perf.data includes two event types: hardware and software event.

 # perf record -e branches:u -c 1 -d -e raw_syscalls:sys_enter ls
 (... ls outputs)
[ perf record: Woken up 18 times to write data ]
[ perf record: Captured and wrote 4.468 MB perf.data (~195216 samples) ]
 # perf bts trace
  Fatal: non matching sample_type

It results in error. Other perf subcommands also failed on this recorded data. For example, perf annotate, perf script, perf report.

In the future, I would like to analyze BTS log and other type events at the same time.

Quoted 5 lines

Well, when you launch the tool you can iterate into the session->header.attr and check if there is something else than a branch perf event. And then emit a warning if so.

Quoted 8 lines

That doesn't solve the problem but the user will know there is one.

Actually the best would be to select PERF_SAMPLE_ID in the sample_type on record and also PERF_FORMAT_ID in the read_format.

Then you can find the PERF_SAMPLE_ID that matches your event. If we record that in the perf headers we can retrieve which events id are the branch ones.

Agreed.

Quoted 2 lines

But well, that's a secondary problem for now.

Thank you for your advise!

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 3 lines
------------------------------------
Akihiro Nagai
Email: [email protected]
#12 lore raw

PATCH v2 3/6 perf bts trace: print pid and command

In reply to Akihiro Nagai

Provide the function of printing pid and command name to 'perf bts trace'. Users can select items to print with options. For example,
'perf bts -p trace' prints only pid,
'perf bts -ac trace' prints address and comamnd name. 'perf bts trace' prints only address (default)

This is output sample (perf bts -ac trace):

command      address
ls           0xffffffff8146fe0e => ls           0x0000003806200b20
ls           0xffffffff8146fe0e => ls           0x0000003806200b20
ls           0x0000003806200b23 => ls           0x0000003806204910
ls           0xffffffff8146fe0e => ls           0x0000003806204910
ls           0xffffffff8146fe0e => ls           0x0000003806204936
ls           0xffffffff8146fe0e => ls           0x000000380620493d
ls           0x0000003806204981 => ls           0x00000038062049a3
ls           0x00000038062049a7 => ls           0x0000003806204988
Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |   18 ++++-
 tools/perf/builtin-bts.c              |  128 +++++++++++++++++++++++++++++++--
 2 files changed, 137 insertions(+), 9 deletions(-)
tools/perf/Documentation/perf-bts.txt +15 -3
index 5920dcc..56ddaa4 100644
@@ -3,7 +3,7 @@ perf-bts(1)
 
 NAME
 ----
-perf-bts - Record and print branch-trace-store log
+perf-bts - Record and analyze branch-trace-store log
 
 SYNOPSIS
 --------
@@ -12,20 +12,32 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-This command can record and print branch-trace-store log.
+This command can record and analyze branch-trace-store log.
 Branch-trace-store is a facility of processors. It can record
 address of branch to/from on every branch instruction and interrupt.
 
 'perf bts record <command>' records branch-trace-store log while specified
 command is executing. And, save to the file "perf.data".
 
-'perf bts trace' parses recorded branch-trace-store log and prints it.
+'perf bts trace' analyzes recorded branch-trace-store log and prints it.
+The command can select the item to print. For example,
+  'perf bts -a trace'	: prints only address
+  'perf bts -acp trace'	: prints address, command name and pid
 
 OPTIONS
 -------
 -i::
 --input=::
         Specify input file name to analyze.
+-a::
+--addr::
+	Print address. (default)
+-c::
+--comm::
+	Print command name.
+-p::
+--pid::
+	Print pid.
 
 SEE ALSO
 --------
tools/perf/builtin-bts.c +122 -6

166 lines not on this page · raw message

#13 lore raw

PATCH v2 4/6 perf bts trace: print file path of the executed elf

In reply to Akihiro Nagai

Provide the function to print file path to the executed elf. Users can enable it with option '-e' or '--elfpath'. For example,
'perf bts -ae trace'
This command prints address and file path of elf. And, output is:

address elf_filepath
0xffffffff8145814e /lib/modules/2.6.37-rc6-tip+/build/vmlinux => 0x0000003806200b20 /lib64/ld-2.12.90.so 0xffffffff8145814e /lib/modules/2.6.37-rc6-tip+/build/vmlinux => 0x0000003806200b20 /lib64/ld-2.12.90.so
0x0000003806200b23 /lib64/ld-2.12.90.so => 0x0000003806204910 /lib64/ld-2.12.90.so
0xffffffff8145814e /lib/modules/2.6.37-rc6-tip+/build/vmlinux => 0x0000003806204910 /lib64/ld-2.12.90.so 0xffffffff8145814e /lib/modules/2.6.37-rc6-tip+/build/vmlinux => 0x0000003806204936 /lib64/ld-2.12.90.so 0xffffffff8145814e /lib/modules/2.6.37-rc6-tip+/build/vmlinux => 0x000000380620493d /lib64/ld-2.12.90.so
0x0000003806204981 /lib64/ld-2.12.90.so => 0x00000038062049a3 /lib64/ld-2.12.90.so
0x00000038062049a7 /lib64/ld-2.12.90.so => 0x0000003806204988 /lib64/ld-2.12.90.so
...

Changes in V2:
- add comment

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |    3 +++
 tools/perf/builtin-bts.c              |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)
tools/perf/Documentation/perf-bts.txt +3 -0
index 56ddaa4..acabffc 100644
@@ -38,6 +38,9 @@ OPTIONS
 -p::
 --pid::
 	Print pid.
+-e::
+--elfpath::
+	Print file path of executed elf.
 
 SEE ALSO
 --------
tools/perf/builtin-bts.c +32 -0
index 525bcd3..1e82c89 100644
@@ -20,6 +20,7 @@ struct exec_info {
 	u64		addr;		/* recorded address by bts */
 	pid_t		pid;		/* tracee process pid */
 	const char	*comm;		/* command name */
+	const char	*elfpath;	/* file path to elf */
 };
 
 #define EI_PID_UNSET	-1
@@ -28,6 +29,7 @@ struct exec_info {
 #define EI_FLAG_PRINT_ADDR		(1 << 0)
 #define EI_FLAG_PRINT_PID		(1 << 1)
 #define EI_FLAG_PRINT_COMM		(1 << 2)
+#define EI_FLAG_PRINT_ELFPATH		(1 << 3)
 
 /* it's used when no print item specified */
 #define EI_FLAG_PRINT_DEFAULT		EI_FLAG_PRINT_ADDR
@@ -77,6 +79,9 @@ static const struct option bts_options[] = {
 	OPT_CALLBACK_DEFAULT_NOOPT('c', "comm", NULL, NULL,
 				   "print command name", set_print_flags,
 				   (void *)EI_FLAG_PRINT_COMM),
+	OPT_CALLBACK_DEFAULT_NOOPT('e', "elfpath", NULL, NULL,
+				   "print file path to elf", set_print_flags,
+				   (void *)EI_FLAG_PRINT_ELFPATH),
 	OPT_END()
 };
 
@@ -91,6 +96,7 @@ static void fill_exec_info(struct exec_info *ei, struct perf_session *session,
 						event_t *event, u64 addr)
 {
 	struct thread *thread;
+	struct addr_location al;
 
 	ei->addr = addr;
 	ei->pid = event->ip.pid;
@@ -99,12 +105,26 @@ static void fill_exec_info(struct exec_info *ei, struct perf_session *session,
 	if (!thread)
 		return;
 	ei->comm = thread->comm;
+
+	/* get file path to elf */
+	memset(&al, 0, sizeof(al));
+	thread__find_addr_map(thread, session, PERF_RECORD_MISC_USER,
+			      MAP__FUNCTION, event->ip.pid, addr, &al);
+	if (!al.map)
+		thread__find_addr_map(thread, session, PERF_RECORD_MISC_KERNEL,
+				      MAP__FUNCTION, event->ip.pid, addr, &al);
+	if (!al.map)
+		return;
+	/* resolve vmlinux path */
+	map__load(al.map, NULL);
+	ei->elfpath = al.map->dso->long_name;
 }
 
 static void __print_exec_info(struct exec_info *ei)
 {
 	char pid[16];
 	const char *comm;
+	const char *elfpath;
 
 	if (print_flags & EI_FLAG_PRINT_PID) {
 		if (ei->pid == EI_PID_UNSET)
@@ -119,6 +139,10 @@ static void __print_exec_info(struct exec_info *ei)
 	}
 	if (print_flags & EI_FLAG_PRINT_ADDR)
 		printf(FMT_ADDR " ", ei->addr);
+	if (print_flags & EI_FLAG_PRINT_ELFPATH) {
+		elfpath = ei->elfpath ? : EI_UNKNOWN_TEXT;
+		printf("%-32s ", elfpath);
+	}
 }
 
 static void print_exec_info(struct exec_info *ei_from, struct exec_info *ei_to)
@@ -137,6 +161,8 @@ static void print_exec_info_header(void)
 		printf("%-12s ", "command");
 	if (print_flags & EI_FLAG_PRINT_ADDR)
 		printf("%-" FMT_ADDR_WIDTH "s ", "address");
+	if (print_flags & EI_FLAG_PRINT_ELFPATH)
+		printf("%-32s ", "elf_filepath");
 	printf("\n");
 }
 
@@ -160,6 +186,7 @@ static int process_sample_event(event_t *event, struct sample_data *sample,
 static struct perf_event_ops event_ops = {
 	.sample			= process_sample_event,
 	.comm			= event__process_comm,
+	.mmap			= event__process_mmap,
 	.ordered_samples	= false,
 };
 
@@ -177,6 +204,11 @@ static int __cmd_trace(void)
 	if (is_flags_unset(print_flags))
 		print_flags = EI_FLAG_PRINT_DEFAULT;
 
+	/* setup kernel maps to resolve vmlinux file path */
+	perf_session__create_kernel_maps(session);
+	if (symbol__init() < 0)
+		fprintf(stderr, "failed to initialize symbol.\n");
+
 	setup_pager();
 	print_exec_info_header();
 	perf_session__process_events(session, &event_ops);
#14 lore raw

PATCH v2 5/6 perf bts trace: print function+offset

In reply to Akihiro Nagai

Provide the function to print function+offset.
And, set it as the default behavior of 'perf bts trace'.
To use this function, users can also specify the option '-s' or '--symbol'.

Example: 'perf bts -as trace'
This command prints address and function+offset.

Output sample:
address function+offset
0xffffffff8146fe0e irq_return+0x0 => 0x00007fd4038e3b20 _start+0x0
...
0x000000380661ee79 __libc_start_main+0xf9 => 0x00000000004035c3 main+0x0

0xffffffff8146ef4e irq_return+0x0         => 0x00000000004035c3 main+0x0
0x00000000004035e8 main+0x25              => 0x000000000040bca0 set_program_name+0x0
0xffffffff8146ef4e irq_return+0x0         => 0x000000000040bca0 set_program_name+0x0
0x000000000040bcae set_program_name+0xe   => 0x00000000004023d0 strrchr@plt+0x0
0x00000000004023d0 strrchr@plt+0x0        => 0x00000000004023d6 strrchr@plt+0x6
...
0x0000000000403e0c main+0x849             => 0x00000000004021f0 exit@plt+0x0
0x00000000004021f0 exit@plt+0x0           => 0x00000000004021f6 exit@plt+0x6
0x00000000004021fb exit@plt+0xb           => 0x00000000004020d0 _init+0x18
0x00000000004020d6 _init+0x1e             => 0x00000038062149d0 _dl_runtime_resolve+0x0

...

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |    5 +++-
 tools/perf/builtin-bts.c              |   45 +++++++++++++++++++++++++++++----
 2 files changed, 44 insertions(+), 6 deletions(-)
tools/perf/Documentation/perf-bts.txt +4 -1
index acabffc..13ee862 100644
@@ -31,7 +31,7 @@ OPTIONS
         Specify input file name to analyze.
 -a::
 --addr::
-	Print address. (default)
+	Print address.
 -c::
 --comm::
 	Print command name.
@@ -41,6 +41,9 @@ OPTIONS
 -e::
 --elfpath::
 	Print file path of executed elf.
+-s::
+--symbol::
+	Print function name and offset. (default)
 
 SEE ALSO
 --------
tools/perf/builtin-bts.c +40 -5

108 lines not on this page · raw message

#15 lore raw

PATCH v2 6/6 perf bts trace: add print all option

In reply to Akihiro Nagai

For ease of use, add option printing all information '-A' or '--all'. This option can print following information.
- pid
- command name
- address
- function+offset
- elf file path

Cc Peter Zijlstra <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-bts.txt |    3 +++
 tools/perf/builtin-bts.c              |    6 ++++++
 2 files changed, 9 insertions(+), 0 deletions(-)
tools/perf/Documentation/perf-bts.txt +3 -0
index 13ee862..c598dd2 100644
@@ -44,6 +44,9 @@ OPTIONS
 -s::
 --symbol::
 	Print function name and offset. (default)
+-A::
+--all::
+	Print all information.
 
 SEE ALSO
 --------
tools/perf/builtin-bts.c +6 -0
index be57571..bac4e83 100644
@@ -34,6 +34,9 @@ struct exec_info {
 #define EI_FLAG_PRINT_ELFPATH		(1 << 3)
 #define EI_FLAG_PRINT_SYMBOL		(1 << 4)
 
+/* all print flags are enabled */
+#define	 EI_FLAG_PRINT_ALL		-1UL
+
 /* it's used when no print item specified */
 #define EI_FLAG_PRINT_DEFAULT		EI_FLAG_PRINT_SYMBOL
 
@@ -92,6 +95,9 @@ static const struct option bts_options[] = {
 				   "print function+offset (default)",
 				   set_print_flags,
 				   (void *)EI_FLAG_PRINT_SYMBOL),
+	OPT_CALLBACK_DEFAULT_NOOPT('A', "all", NULL, NULL,
+				   "print all items", set_print_flags,
+				   (void *)EI_FLAG_PRINT_ALL),
 	OPT_END()
 };
 
#16 lore raw
In reply to Akihiro Nagai
Quoted 13 lines · Akihiro Nagai

Hi,

This patch series provides the commands 'perf bts record' and 'perf bts trace' version 2. These commands can record and analyze BTS (Branch Trace Store) log. And, provide the interface to use BTS log for application developers.

BTS is a facility of Intel x86 processors, which can record the address of 'branch to/from' on every branch/jump instruction and interrupt. This facility is very useful for developers to test their software. For example, coverage test, execution path analysis, dynamic step count ...etc. Also, those tools can have a very big advantage that they don't require any changes of the target executable binaries.

Quoted 4 lines

But, there are few applications using BTS. Reasons I guess are ...
- Few people know what BTS is.
- Few people know how to use BTS on Linux box.
- It's hard to analyze the BTS log because it includes just a series of addresses.

And I would add:

- It has a big overhead, probably because the CPU spends some time to record the branches, but also because it generates a huge amount of traces to save periodically.

- It seems it's only available on intel CPUs (and some of them)

- It can't do branch type filtering like LBR does on some intel CPUs. Like recording only call and ret branches and ignore jmp, je, etc... which would make lower overhead if our goal is to trace only the function graph for example.

OTOH it has a great potential.

Quoted 7 lines

So, I want to provide a user-friendly interface to BTS for application developers.

About new sub commands
========================
'perf bts record' provides the easy way to record bts log.

I would suggest to call it perf branch. Bts beeing only an underlying backend feature that makes it working. An implementation detail. For example, the function graph traces may join in the future to provide some branch details of the kernel, only in the function level of course.

Quoted 19 lines

Usage is 'perf bts record <command>'. This command is just an alias to 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and more intuitive.

'perf bts trace' can parse and analyze recorded bts log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Example: 'perf bts trace'
function+offset

irq_return+0x0  => _start+0x0
irq_return+0x0  => _start+0x0
_start+0x3      => _dl_start+0x0
irq_return+0x0  => _dl_start+0x0
irq_return+0x0  => _dl_start+0x26
irq_return+0x0  => _dl_start+0x2d
_dl_start+0x71  => _dl_start+0x93
_dl_start+0x97  => _dl_start+0x78
Quoted 3 lines

...

This is the default behavior of 'perf bts trace'. It prints function+offset.

That's a good start!

I suspect in the future, the default should be a function graph layout and only dive into in-proc branch details if requested by means of options.

But may be I'm biaised and in practice we need to output the branches right away. That said I suspect a function graph should give the first desired overview.

This can probably be done incrementally though, this output is already a nice feature.

Quoted 10 lines

Example2: 'perf bts -cas trace'
command address function+offset

ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806200b20 _start+0x0
ls      0x0000003806200b23 _start+0x3      => ls   0x0000003806204910 _dl_start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204910 _dl_start+0x0
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x0000003806204936 _dl_start+0x26
ls      0xffffffff8146fe0e irq_return+0x0  => ls   0x000000380620493d _dl_start+0x2d
ls      0x0000003806204981 _dl_start+0x71  => ls   0x00000038062049a3 _dl_start+0x93
ls      0x00000038062049a7 _dl_start+0x97  => ls   0x0000003806204988 _dl_start+0x78

Cool!

Quoted 10 lines

...

In the future, I'd like to make this more informative. For example
- Show source file path
- Show line number
- Show inlined function name
- Draw call graph
- Browse source code and coloring
- Make bts record fast
and more!

Very nice plans.

Thanks!