perf: Introduce bts sub commands
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])
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.dataChanges in V2:
- Update to the latest -tip tree
- add bts explanation to the subcommand list
---
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 ;
PATCH v2 2/6 perf bts: Introduce new sub command 'perf bts trace'
In reply to Akihiro NagaiIntroduce 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 => 0x0000003806200b200x0000003806200b23 => 0x00000038062049100xffffffff8146fe0e => 0x00000038062049100xffffffff8146fe0e => 0x00000038062049360xffffffff8146fe0e => 0x000000380620493d0x0000003806204981 => 0x00000038062049a30x00000038062049a7 => 0x0000003806204988
...
Changes in V2:
- Update to the latest -tip tree
---
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
@@ -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
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=>0x0000003806200b200x0000003806200b23=>0x00000038062049100xffffffff8146fe0e=>0x00000038062049100xffffffff8146fe0e=>0x00000038062049360xffffffff8146fe0e=>0x000000380620493d0x0000003806204981=>0x00000038062049a30x00000038062049a7=>0x0000003806204988
...Changes in V2:
- Update to the latest -tip treeSigned-off-by Akihiro Nagai <[email protected]>Reviewed-by Masami Hiramatsu <[email protected]>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@@ -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@@ -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
-0static 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.
Peter Zijlstra
maintainerRe: [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_IDin thesample_typeon record and alsoPERF_FORMAT_IDin theread_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.
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_IDin thesample_typeon record and alsoPERF_FORMAT_IDin theread_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.
Peter Zijlstra
maintainerRe: [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_IDin thesample_typeon record and alsoPERF_FORMAT_IDin theread_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.
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_IDin thesample_typeon record and alsoPERF_FORMAT_IDin theread_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_SAMPLEbits.
But we may actually want the time and pid bits.
This could be a PERF_SAMPLE_RAW may be?
Peter Zijlstra
maintainerRe: [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_RAWmay 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.
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_RAWmay 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_sampleisPERF_RECORD_SAMPLEwithout theperf_event_headerbit.Where we can split the many samples into a piece that is the same for all
perf_samples::common, where the content specified by thePERF_SAMPLE_bits from ::common_type, and the the rest lives in data[] specified by thePERF_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...
Peter Zijlstra
maintainerRe: [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_RAWmay 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_sampleisPERF_RECORD_SAMPLEwithout theperf_event_headerbit.
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 thePERF_SAMPLE_bits from ::common_type, and the the rest lives in data[] specified by thePERF_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)
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.attrand 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_IDin thesample_typeon record and alsoPERF_FORMAT_IDin theread_format.Then you can find the
PERF_SAMPLE_IDthat 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]
PATCH v2 3/6 perf bts trace: print pid and command
In reply to Akihiro NagaiProvide 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
---
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
@@ -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
PATCH v2 4/6 perf bts trace: print file path of the executed elf
In reply to Akihiro NagaiProvide 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_filepath0xffffffff8145814e /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.so0x0000003806200b23 /lib64/ld-2.12.90.so => 0x0000003806204910 /lib64/ld-2.12.90.so0xffffffff8145814e /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.so0x0000003806204981 /lib64/ld-2.12.90.so => 0x00000038062049a3 /lib64/ld-2.12.90.so0x00000038062049a7 /lib64/ld-2.12.90.so => 0x0000003806204988 /lib64/ld-2.12.90.so
...
Changes in V2:
- add comment
---
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
@@ -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
@@ -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);
PATCH v2 5/6 perf bts trace: print function+offset
In reply to Akihiro NagaiProvide 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+offset0xffffffff8146fe0e 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
...
---
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
@@ -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
PATCH v2 6/6 perf bts trace: add print all option
In reply to Akihiro NagaiFor 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
---
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
@@ -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
@@ -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() };
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+offsetirq_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+offsetls 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!