perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
/*
|
|
|
|
* builtin-test.c
|
|
|
|
*
|
|
|
|
* Builtin regression testing command: ever growing number of sanity tests
|
|
|
|
*/
|
2014-05-10 23:22:30 +08:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <string.h>
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
#include "builtin.h"
|
2013-01-25 03:22:55 +08:00
|
|
|
#include "intlist.h"
|
2012-11-10 08:46:41 +08:00
|
|
|
#include "tests.h"
|
2012-11-10 08:46:51 +08:00
|
|
|
#include "debug.h"
|
|
|
|
#include "color.h"
|
|
|
|
#include "parse-options.h"
|
|
|
|
#include "symbol.h"
|
2011-01-04 21:55:27 +08:00
|
|
|
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
static struct test {
|
|
|
|
const char *desc;
|
|
|
|
int (*func)(void);
|
|
|
|
} tests[] = {
|
|
|
|
{
|
|
|
|
.desc = "vmlinux symtab matches kallsyms",
|
|
|
|
.func = test__vmlinux_matches_kallsyms,
|
|
|
|
},
|
2011-01-04 10:16:20 +08:00
|
|
|
{
|
|
|
|
.desc = "detect open syscall event",
|
|
|
|
.func = test__open_syscall_event,
|
|
|
|
},
|
2011-01-04 21:55:27 +08:00
|
|
|
{
|
|
|
|
.desc = "detect open syscall event on all cpus",
|
|
|
|
.func = test__open_syscall_event_on_all_cpus,
|
|
|
|
},
|
2011-01-15 20:42:46 +08:00
|
|
|
{
|
|
|
|
.desc = "read samples using the mmap interface",
|
|
|
|
.func = test__basic_mmap,
|
|
|
|
},
|
2011-07-14 17:25:33 +08:00
|
|
|
{
|
|
|
|
.desc = "parse events tests",
|
2012-11-10 08:46:51 +08:00
|
|
|
.func = test__parse_events,
|
2011-07-14 17:25:33 +08:00
|
|
|
},
|
2011-11-21 21:42:47 +08:00
|
|
|
#if defined(__x86_64__) || defined(__i386__)
|
|
|
|
{
|
|
|
|
.desc = "x86 rdpmc test",
|
|
|
|
.func = test__rdpmc,
|
|
|
|
},
|
|
|
|
#endif
|
2011-12-02 21:13:50 +08:00
|
|
|
{
|
|
|
|
.desc = "Validate PERF_RECORD_* events & perf_sample fields",
|
|
|
|
.func = test__PERF_RECORD,
|
|
|
|
},
|
2012-03-16 03:09:17 +08:00
|
|
|
{
|
|
|
|
.desc = "Test perf pmu format parsing",
|
2012-11-10 08:46:50 +08:00
|
|
|
.func = test__pmu,
|
2012-03-16 03:09:17 +08:00
|
|
|
},
|
2012-07-22 20:14:40 +08:00
|
|
|
{
|
2014-05-12 20:43:53 +08:00
|
|
|
.desc = "Test dso data read",
|
2012-11-10 08:46:51 +08:00
|
|
|
.func = test__dso_data,
|
2012-07-22 20:14:40 +08:00
|
|
|
},
|
2014-05-12 20:43:53 +08:00
|
|
|
{
|
|
|
|
.desc = "Test dso data cache",
|
|
|
|
.func = test__dso_data_cache,
|
|
|
|
},
|
2012-09-07 00:11:18 +08:00
|
|
|
{
|
|
|
|
.desc = "roundtrip evsel->name check",
|
2012-11-10 08:46:47 +08:00
|
|
|
.func = test__perf_evsel__roundtrip_name_test,
|
2012-09-07 00:11:18 +08:00
|
|
|
},
|
2012-09-18 22:56:28 +08:00
|
|
|
{
|
|
|
|
.desc = "Check parsing of sched tracepoints fields",
|
2012-11-10 08:46:48 +08:00
|
|
|
.func = test__perf_evsel__tp_sched_test,
|
2012-09-18 22:56:28 +08:00
|
|
|
},
|
2012-09-27 00:23:10 +08:00
|
|
|
{
|
|
|
|
.desc = "Generate and check syscalls:sys_enter_open event fields",
|
|
|
|
.func = test__syscall_open_tp_fields,
|
|
|
|
},
|
2012-10-31 06:02:05 +08:00
|
|
|
{
|
|
|
|
.desc = "struct perf_event_attr setup",
|
2012-11-10 08:46:51 +08:00
|
|
|
.func = test__attr,
|
2012-10-31 06:02:05 +08:00
|
|
|
},
|
2012-12-10 16:29:57 +08:00
|
|
|
{
|
2013-05-23 18:08:38 +08:00
|
|
|
.desc = "Test matching and linking multiple hists",
|
2012-12-10 16:29:57 +08:00
|
|
|
.func = test__hists_link,
|
|
|
|
},
|
2012-12-15 00:06:13 +08:00
|
|
|
{
|
|
|
|
.desc = "Try 'use perf' in python, checking link problems",
|
|
|
|
.func = test__python_use,
|
|
|
|
},
|
2013-03-11 02:41:10 +08:00
|
|
|
{
|
|
|
|
.desc = "Test breakpoint overflow signal handler",
|
|
|
|
.func = test__bp_signal,
|
|
|
|
},
|
2013-03-11 02:41:11 +08:00
|
|
|
{
|
|
|
|
.desc = "Test breakpoint overflow sampling",
|
|
|
|
.func = test__bp_signal_overflow,
|
|
|
|
},
|
2013-03-15 13:58:11 +08:00
|
|
|
{
|
|
|
|
.desc = "Test number of exit event of a simple workload",
|
|
|
|
.func = test__task_exit,
|
|
|
|
},
|
2013-03-18 10:41:47 +08:00
|
|
|
{
|
|
|
|
.desc = "Test software clock events have valid period values",
|
|
|
|
.func = test__sw_clock_freq,
|
|
|
|
},
|
2013-06-28 21:22:19 +08:00
|
|
|
#if defined(__x86_64__) || defined(__i386__)
|
|
|
|
{
|
|
|
|
.desc = "Test converting perf time to TSC",
|
|
|
|
.func = test__perf_time_to_tsc,
|
|
|
|
},
|
|
|
|
#endif
|
2013-08-07 19:38:45 +08:00
|
|
|
{
|
|
|
|
.desc = "Test object code reading",
|
|
|
|
.func = test__code_reading,
|
|
|
|
},
|
2013-08-27 16:23:13 +08:00
|
|
|
{
|
|
|
|
.desc = "Test sample parsing",
|
|
|
|
.func = test__sample_parsing,
|
|
|
|
},
|
2013-09-01 02:50:53 +08:00
|
|
|
{
|
|
|
|
.desc = "Test using a dummy software event to keep tracking",
|
|
|
|
.func = test__keep_tracking,
|
|
|
|
},
|
2013-09-05 04:18:16 +08:00
|
|
|
{
|
|
|
|
.desc = "Test parsing with no sample_id_all bit set",
|
|
|
|
.func = test__parse_no_sample_id_all,
|
|
|
|
},
|
2014-05-16 16:41:11 +08:00
|
|
|
#if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
|
2014-01-07 20:47:28 +08:00
|
|
|
#ifdef HAVE_DWARF_UNWIND_SUPPORT
|
2014-01-07 20:47:22 +08:00
|
|
|
{
|
|
|
|
.desc = "Test dwarf unwind",
|
|
|
|
.func = test__dwarf_unwind,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
#endif
|
2014-04-25 11:28:14 +08:00
|
|
|
{
|
|
|
|
.desc = "Test filtering hist entries",
|
|
|
|
.func = test__hists_filter,
|
|
|
|
},
|
2014-03-06 00:20:31 +08:00
|
|
|
{
|
|
|
|
.desc = "Test mmap thread lookup",
|
|
|
|
.func = test__mmap_thread_lookup,
|
|
|
|
},
|
2014-03-17 21:39:00 +08:00
|
|
|
{
|
|
|
|
.desc = "Test thread mg sharing",
|
|
|
|
.func = test__thread_mg_share,
|
|
|
|
},
|
2014-05-12 13:43:18 +08:00
|
|
|
{
|
|
|
|
.desc = "Test output sorting of hist entries",
|
|
|
|
.func = test__hists_output,
|
|
|
|
},
|
2014-05-23 17:04:42 +08:00
|
|
|
{
|
|
|
|
.desc = "Test cumulation of child hist entries",
|
|
|
|
.func = test__hists_cumulate,
|
|
|
|
},
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
{
|
|
|
|
.func = NULL,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2011-11-29 22:52:07 +08:00
|
|
|
static bool perf_test__matches(int curr, int argc, const char *argv[])
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
{
|
2011-11-29 22:52:07 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (argc == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (i = 0; i < argc; ++i) {
|
|
|
|
char *end;
|
|
|
|
long nr = strtoul(argv[i], &end, 10);
|
|
|
|
|
|
|
|
if (*end == '\0') {
|
|
|
|
if (nr == curr + 1)
|
|
|
|
return true;
|
|
|
|
continue;
|
|
|
|
}
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
|
2011-11-29 22:52:07 +08:00
|
|
|
if (strstr(tests[curr].desc, argv[i]))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-05-10 23:22:30 +08:00
|
|
|
static int run_test(struct test *test)
|
|
|
|
{
|
|
|
|
int status, err = -1, child = fork();
|
|
|
|
|
|
|
|
if (child < 0) {
|
|
|
|
pr_err("failed to fork test: %s\n", strerror(errno));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!child) {
|
|
|
|
pr_debug("test child forked, pid %d\n", getpid());
|
|
|
|
err = test->func();
|
|
|
|
exit(err);
|
|
|
|
}
|
|
|
|
|
|
|
|
wait(&status);
|
|
|
|
|
|
|
|
if (WIFEXITED(status)) {
|
|
|
|
err = WEXITSTATUS(status);
|
|
|
|
pr_debug("test child finished with %d\n", err);
|
|
|
|
} else if (WIFSIGNALED(status)) {
|
|
|
|
err = -1;
|
|
|
|
pr_debug("test child interrupted\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2013-01-25 03:22:55 +08:00
|
|
|
static int __cmd_test(int argc, const char *argv[], struct intlist *skiplist)
|
2011-11-29 22:52:07 +08:00
|
|
|
{
|
|
|
|
int i = 0;
|
2012-10-25 01:44:41 +08:00
|
|
|
int width = 0;
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
|
2012-10-25 01:44:41 +08:00
|
|
|
while (tests[i].func) {
|
|
|
|
int len = strlen(tests[i].desc);
|
|
|
|
|
|
|
|
if (width < len)
|
|
|
|
width = len;
|
|
|
|
++i;
|
|
|
|
}
|
2012-10-31 06:01:43 +08:00
|
|
|
|
2012-10-25 01:44:41 +08:00
|
|
|
i = 0;
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
while (tests[i].func) {
|
2011-11-29 22:52:07 +08:00
|
|
|
int curr = i++, err;
|
|
|
|
|
|
|
|
if (!perf_test__matches(curr, argc, argv))
|
|
|
|
continue;
|
|
|
|
|
2012-10-25 01:44:41 +08:00
|
|
|
pr_info("%2d: %-*s:", i, width, tests[curr].desc);
|
2013-01-25 03:22:55 +08:00
|
|
|
|
|
|
|
if (intlist__find(skiplist, i)) {
|
|
|
|
color_fprintf(stderr, PERF_COLOR_YELLOW, " Skip (user override)\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
pr_debug("\n--- start ---\n");
|
2014-05-10 23:22:30 +08:00
|
|
|
err = run_test(&tests[curr]);
|
2011-11-29 22:52:07 +08:00
|
|
|
pr_debug("---- end ----\n%s:", tests[curr].desc);
|
2012-12-19 22:33:39 +08:00
|
|
|
|
|
|
|
switch (err) {
|
|
|
|
case TEST_OK:
|
2012-10-25 01:44:41 +08:00
|
|
|
pr_info(" Ok\n");
|
2012-12-19 22:33:39 +08:00
|
|
|
break;
|
|
|
|
case TEST_SKIP:
|
|
|
|
color_fprintf(stderr, PERF_COLOR_YELLOW, " Skip\n");
|
|
|
|
break;
|
|
|
|
case TEST_FAIL:
|
|
|
|
default:
|
|
|
|
color_fprintf(stderr, PERF_COLOR_RED, " FAILED!\n");
|
|
|
|
break;
|
|
|
|
}
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-11-29 22:52:07 +08:00
|
|
|
static int perf_test__list(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
while (tests[i].func) {
|
|
|
|
int curr = i++;
|
|
|
|
|
|
|
|
if (argc > 1 && !strstr(tests[curr].desc, argv[1]))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
pr_info("%2d: %s\n", i, tests[curr].desc);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
|
2012-09-11 06:15:03 +08:00
|
|
|
int cmd_test(int argc, const char **argv, const char *prefix __maybe_unused)
|
2011-11-29 22:52:07 +08:00
|
|
|
{
|
|
|
|
const char * const test_usage[] = {
|
|
|
|
"perf test [<options>] [{list <test-name-fragment>|[<test-name-fragments>|<test-numbers>]}]",
|
|
|
|
NULL,
|
|
|
|
};
|
2013-01-25 03:22:55 +08:00
|
|
|
const char *skip = NULL;
|
2011-11-29 22:52:07 +08:00
|
|
|
const struct option test_options[] = {
|
2013-01-25 03:22:55 +08:00
|
|
|
OPT_STRING('s', "skip", &skip, "tests", "tests to skip"),
|
2012-01-08 01:25:26 +08:00
|
|
|
OPT_INCR('v', "verbose", &verbose,
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
"be more verbose (show symbol address, etc)"),
|
|
|
|
OPT_END()
|
2011-11-29 22:52:07 +08:00
|
|
|
};
|
2013-01-25 03:22:55 +08:00
|
|
|
struct intlist *skiplist = NULL;
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
|
|
|
|
argc = parse_options(argc, argv, test_options, test_usage, 0);
|
2011-11-29 22:52:07 +08:00
|
|
|
if (argc >= 1 && !strcmp(argv[0], "list"))
|
|
|
|
return perf_test__list(argc, argv);
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
|
|
|
|
symbol_conf.priv_size = sizeof(int);
|
|
|
|
symbol_conf.sort_by_name = true;
|
|
|
|
symbol_conf.try_vmlinux_path = true;
|
|
|
|
|
|
|
|
if (symbol__init() < 0)
|
|
|
|
return -1;
|
|
|
|
|
2013-01-25 03:22:55 +08:00
|
|
|
if (skip != NULL)
|
|
|
|
skiplist = intlist__new(skip);
|
|
|
|
|
|
|
|
return __cmd_test(argc, argv, skiplist);
|
perf test: Initial regression testing command
First an example with the first internal test:
[acme@doppio linux-2.6-tip]$ perf test
1: vmlinux symtab matches kallsyms: Ok
So it run just one test, that is "vmlinux symtab matches kallsyms", and it was
successful.
If we run it in verbose mode, we'll see details about errors and extra warnings
for non-fatal problems:
[acme@doppio linux-2.6-tip]$ perf test -v
1: vmlinux symtab matches kallsyms:
--- start ---
Looking at the vmlinux_path (5 entries long)
No build_id in vmlinux, ignoring it
No build_id in /boot/vmlinux, ignoring it
No build_id in /boot/vmlinux-2.6.34-rc4-tip+, ignoring it
Using /lib/modules/2.6.34-rc4-tip+/build/vmlinux for symbols
Maps only in vmlinux:
ffffffff81cb81b1-ffffffff81e1149b 0 [kernel].init.text
ffffffff81e1149c-ffffffff9fffffff 0 [kernel].exit.text
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2
Maps in vmlinux with a different name in kallsyms:
ffffffffff600000-ffffffffff6000ff 0 [kernel].vsyscall_0 in kallsyms as [kernel].0
ffffffffff600100-ffffffffff6003ff 0 [kernel].vsyscall_fn in kallsyms as:
*ffffffffff600100-ffffffffff60012f 0 [kernel].2
ffffffffff600400-ffffffffff6007ff 0 [kernel].vsyscall_1 in kallsyms as [kernel].6
ffffffffff600800-ffffffffffffffff 0 [kernel].vsyscall_2 in kallsyms as [kernel].8
Maps only in kallsyms:
ffffffffff600130-ffffffffff6003ff 0 [kernel].4
---- end ----
vmlinux symtab matches kallsyms: Ok
[acme@doppio linux-2.6-tip]$
In the above case we only know the name of the non contiguous kernel ranges in
the address space when reading the symbol information from the ELF symtab in
vmlinux.
The /proc/kallsyms file lack this, we only notice they are separate because
there are modules after the kernel and after that more kernel functions, so we
need to have a module rbtree backed by the module .ko path to get symtabs in
the vmlinux case.
The tool uses it to match by address to emit appropriate warning, but don't
considers this fatal.
The .init.text and .exit.text ines, of course, aren't in kallsyms, so I left
these cases just as extra info in verbose mode.
The end of the sections also aren't in kallsyms, so we the symbols layer does
another pass and sets the end addresses as the next map start minus one, which
sometimes pads, causing harmless mismatches.
But at least the symbols match, tested it by copying /proc/kallsyms to
/tmp/kallsyms and doing changes to see if they were detected.
This first test also should serve as a first stab at documenting the
symbol library by providing a self contained example that exercises it
together with comments about what is being done.
More tests to check if actions done on a monitored app, like doing mmaps, etc,
makes the kernel generate the expected events should be added next.
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2010-04-30 05:58:32 +08:00
|
|
|
}
|