- 08 Jun, 2015 14 commits
-
-
Arnaldo Carvalho de Melo authored
To allow concurrent access, next step: refcount struct dso instances, so that we can ditch unused them when the last map pointing to it goes away. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-yk1k08etpd2aoe3tnrf0oizn@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
Calling the function 'machine__new_module' implies a new 'module' will be allocated, when in fact what is returned is a 'struct map' instance, that not necessarily will be instantiated, as if one already exists with the given module name, it will be returned instead. So be consistent with other "find and if not there, create" like functions, like machine__findnew_thread, machine__findnew_dso, etc, and rename it to machine__findnew_module_map(), that in turn will call machine__findnew_module_dso(). Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-acv830vd3hwww2ih5vjtbmu3@git.kernel.orgSigned-off-by:
-
He Kuang authored
The size of perf.data is missing update in no-buildid mode, which gives wrong output result. Before this patch: $ perf.perf record -B -e syscalls:sys_enter_open uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.000 MB perf.data ] After this patch: $ perf.perf record -B -e syscalls:sys_enter_open uname Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.001 MB perf.data ] Signed-off-by:
He Kuang <hekuang@huawei.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1432819050-30511-1-git-send-email-hekuang@huawei.comSigned-off-by:
-
He Kuang authored
The libtrace-dynamic-list file is used to export symbols used by traceevent plugins. Signed-off-by:
-
He Kuang authored
Traceevent plugins need dynamic symbols exported from libtraceevent.a, otherwise a dlopen error will occur during plugins loading. This patch uses dynamic-list-file to export dynamic symbols which will be used in plugins to perf executable. The problem is covered up if feature-libpython is enabled, because PYTHON_EMBED_LDOPTS contains '-Xlinker --export-dynamic' which adds all symbols to the dynamic symbol table. So we should reproduce the problem by setting NO_LIBPYTHON=1. Before this patch: (Prepare plugins) $ ls /root/.traceevent/plugins/ plugin_sched_switch.so plugin_function.so ... $ perf record -e 'ftrace:function' ls $ perf script Warning: could not load plugin '/mnt/data/root/.traceevent/plugins/plugin_sched_switch.so' /root/.traceevent/plugins/plugin_sched_switch.so: undefined symbol: pevent_unregister_event_handler Warning: could not load plugin '/root/.traceevent/plugins/plugin_function.so' /root/.traceevent/plugins/plugin_function.so: undefined symbol: warning ... :1049 1049 [000] 9666.754487: ftrace:function: ffffffff8118bc50 <-- ffffffff8118c5b3 :1049 1049 [000] 9666.754487: ftrace:function: ffffffff818e2440 <-- ffffffff8118bc75 :1049 1049 [000] 9666.754487: ftrace:function: ffffffff8106eee0 <-- ffffffff811212e2 After this patch: $ perf record -e 'ftrace:function' ls $ perf script :1049 1049 [000] 9666.754487: ftrace:function: __set_task_comm :1049 1049 [000] 9666.754487: ftrace:function: _raw_spin_lock :1049 1049 [000] 9666.754487: ftrace:function: task_tgid_nr_ns ... Signed-off-by:Jiri Olsa <jolsa@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1432819735-35040-1-git-send-email-hekuang@huawei.comSigned-off-by:
-
Jiri Olsa authored
Separating shadow counters code into separate object as a cleanup, but mainly for upcomming changes, so could use it from script command context. Signed-off-by:
-
Jiri Olsa authored
As preparation for moving shadow counters code into its own object. Signed-off-by:
-
Jiri Olsa authored
As preparation for moving shadow counters code into its own object. Signed-off-by:
-
Jiri Olsa authored
Move shadow counters display code into separate function as preparation for moving it into its own object. Signed-off-by:
-
Jiri Olsa authored
Move shadow counters reset code into separate function as preparation for moving it into its own object. Signed-off-by:
-
Jiri Olsa authored
It's no longer needed, because we use nameid to recognize transaction events. Keeping it only in stat code to initialize transaction events. I.e. struct perf_stat::id, accessible via evsel->priv, will be only set for transaction related events. Signed-off-by:
-
Jiri Olsa authored
We can use already existing parse_events interface. Both transaction_attrs and transaction_limited_attrs are changed to be single strings. Signed-off-by:
-
Jiri Olsa authored
Using perf_stat::id to check for transaction events, instead of current position based way. Signed-off-by:
-
Jiri Olsa authored
We need fast way to identify evsel as transaction event for shadow counters computation. Currently we are using possition (in evlist) based way. Adding 'id' into 'struct perf_stat' so it can carry transaction event ID and we can use it for shadow counters computations. Signed-off-by:
-
- 07 Jun, 2015 12 commits
-
-
Peter Zijlstra authored
PEBSv3 as present on Skylake fixed the long standing issue of the status bits. They now really reflect the events that generated the record. Tested-by:
Andi Kleen <ak@linux.intel.com> Tested-by:
Kan Liang <kan.liang@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Kan Liang authored
This patch modifies the perf tool to handle the new RECORD type, PERF_RECORD_LOST_SAMPLES. The number of lost-sample events is stored in .nr_events[PERF_RECORD_LOST_SAMPLES]. The exact number of samples which the kernel dropped is stored in total_lost_samples. When the percentage of dropped samples is greater than 5%, a warning is printed. Here are some examples: Eg 1, Recording different frequently-occurring events is safe with the patch. Only a very low drop rate is associated with such actions. $ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain ~/tchain $ perf report -D | tail SAMPLE events: 120243 MMAP2 events: 5 LOST_SAMPLES events: 24 FINISHED_ROUND events: 15 cycles:p stats: TOTAL events: 59348 SAMPLE events: 59348 instructions:p stats: TOTAL events: 60895 SAMPLE events: 60895 $ perf report --stdio --group # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 24 # # Samples: 120K of event 'anon group { cycles:p, instructions:p }' # Event count (approx.): 24048600000 # # Overhead Command Shared Object Symbol # ................ ........... ................ .................................. # 99.74% 99.86% tchain_edit tchain_edit [.] f3 0.09% 0.02% tchain_edit tchain_edit [.] f2 0.04% 0.00% tchain_edit [kernel.vmlinux] [k] ixgbe_read_reg Eg 2, Recording the same thing multiple times can lead to high drop rate, but it is not a useful configuration. $ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain Warning: Processed 600592 samples and lost 99.73% samples! [perf record: Woken up 148 times to write data] [perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)] [perf record: Woken up 1 times to write data] [perf record: Captured and wrote 0.121 MB perf.data (1629 samples)] Signed-off-by: -
Kan Liang authored
After enlarging the PEBS interrupt threshold, there may be some mixed up PEBS samples which are discarded by the kernel. This patch makes the kernel emit a PERF_RECORD_LOST_SAMPLES record with the number of possible discarded records when it is impossible to demux the samples. It makes sure the user is not left in the dark about such discards. Signed-off-by:
-
Yan, Zheng authored
Currently the PEBS buffer size is 4k, it can only hold about 21 PEBS records. This patch enlarges the PEBS buffer size to 64k (the same as the BTS buffer). 64k memory can hold about 330 PEBS records. This will significantly reduce the number of PMIs when batched PEBS interrupts are enabled. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
-
Yan, Zheng authored
Flush the PEBS buffer during context switches if PEBS interrupt threshold is larger than one. This allows perf to supply TID for sample outputs. Signed-off-by:
-
Yan, Zheng authored
PEBS always had the capability to log samples to its buffers without an interrupt. Traditionally perf has not used this but always set the PEBS threshold to one. For frequently occurring events (like cycles or branches or load/store) this in term requires using a relatively high sampling period to avoid overloading the system, by only processing PMIs. This in term increases sampling error. For the common cases we still need to use the PMI because the PEBS hardware has various limitations. The biggest one is that it can not supply a callgraph. It also requires setting a fixed period, as the hardware does not support adaptive period. Another issue is that it cannot supply a time stamp and some other options. To supply a TID it requires flushing on context switch. It can however supply the IP, the load/store address, TSX information, registers, and some other things. So we can make PEBS work for some specific cases, basically as long as you can do without a callgraph and can set the period you can use this new PEBS mode. The main benefit is the ability to support much lower sampling period (down to -c 1000) without extensive overhead. One use cases is for example to increase the resolution of the c2c tool. Another is double checking when you suspect the standard sampling has too much sampling error. Some numbers on the overhead, using cycle soak, comparing the elapsed time from "kernbench -M -H" between plain (threshold set to one) and multi (large threshold). The test command for plain: "perf record --time -e cycles:p -c $period -- kernbench -M -H" The test command for multi: "perf record --no-time -e cycles:p -c $period -- kernbench -M -H" ( The only difference of test command between multi and plain is time stamp options. Since time stamp is not supported by large PEBS threshold, it can be used as a flag to indicate if large threshold is enabled during the test. ) period plain(Sec) multi(Sec) Delta 10003 32.7 16.5 16.2 20003 30.2 16.2 14.0 40003 18.6 14.1 4.5 80003 16.8 14.6 2.2 100003 16.9 14.1 2.8 800003 15.4 15.7 -0.3 1000003 15.3 15.2 0.2 2000003 15.3 15.1 0.1 With periods below 100003, plain (threshold one) cause much more overhead. With 10003 sampling period, the Elapsed Time for multi is even 2X faster than plain. Signed-off-by:
-
Yan, Zheng authored
When the PEBS interrupt threshold is larger than one record and the machine supports multiple PEBS events, the records of these events are mixed up and we need to demultiplex them. Demuxing the records is hard because the hardware is deficient. The hardware has two issues that, when combined, create impossible scenarios to demux. The first issue is that the 'status' field of the PEBS record is a copy of the GLOBAL_STATUS MSR at PEBS assist time. To see why this is a problem let us first describe the regular PEBS cycle: A) the CTRn value reaches 0: - the corresponding bit in GLOBAL_STATUS gets set - we start arming the hardware assist < some unspecified amount of time later -- this could cover multiple events of interest > B) the hardware assist is armed, any next event will trigger it C) a matching event happens: - the hardware assist triggers and generates a PEBS record this includes a copy of GLOBAL_STATUS at this moment - if we auto-reload we (re)set CTRn - we clear the relevant bit in GLOBAL_STATUS Now consider the following chain of events: A0, B0, A1, C0 The event generated for counter 0 will include a status with counter 1 set, even though its not at all related to the record. A similar thing can happen with a !PEBS event if it just happens to overflow at the right moment. The second issue is that the hardware will only emit one record for two or more counters if the event that triggers the assist is 'close'. The 'close' can be several cycles. In some cases even the complete assist, if the event is something that doesn't need retirement. For instance, consider this chain of events: A0, B0, A1, B1, C01 Where C01 is an event that triggers both hardware assists, we will generate but a single record, but again with both counters listed in the status field. This time the record pertains to both events. Note that these two cases are different but undistinguishable with the data as generated. Therefore demuxing records with multiple PEBS bits (we can safely ignore status bits for !PEBS counters) is impossible. Furthermore we cannot emit the record to both events because that might cause a data leak -- the events might not have the same privileges -- so what this patch does is discard such events. The assumption/hope is that such discards will be rare. Here lists some possible ways you may get high discard rate. - when you count the same thing multiple times. But it is not a useful configuration. - you can be unfortunate if you measure with a userspace only PEBS event along with either a kernel or unrestricted PEBS event. Imagine the event triggering and setting the overflow flag right before entering the kernel. Then all kernel side events will end up with multiple bits set. Signed-off-by: -
Yan, Zheng authored
Move code that sets up the PEBS sample data to a separate function. Signed-off-by:
-
Yan, Zheng authored
When a fixed period is specified, this patch makes perf use the PEBS auto reload mechanism. This makes normal profiling faster, because it avoids one costly MSR write in the PMI handler. However, the reset value will be loaded by hardware assist. There is a small delay compared to the previous non-auto-reload mechanism. The delay time is arbitrary, but very small. The assist cost is 400-800 cycles, assuming common cases with everything cached. The minimum period the patch currently uses is 10000. In that extreme case it can be ~10% if cycles are used. Signed-off-by:
-
Stephane Eranian authored
This patch adds a new branch sampling type support for indirect jumps: perf record -j ind_jmp ....... It enables analysis of indirect jumps targets. It requires kernel and possibly hardware support to operate correctly. Signed-off-by:
Stephane Eranian <eranian@google.com> [ Fixup against: f00898f4 (perf tools: Move branch option parsing to own file) ] Signed-off-by:
-
Stephane Eranian authored
This patch enables support for branch sampling filter for indirect jumps (IND_JUMP). It enables LBR IND_JMP filtering where available. There is also software filtering support. Signed-off-by:
-
Stephane Eranian authored
This patch adds a new branch_sample_type flag to enable filtering branch sampling to indirect jumps. The support is subject to hardware or kernel software support on each architecture. Filtering on indirect jump is useful to study the targets of the jump. Signed-off-by:
-
- 04 Jun, 2015 1 commit
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: - Fix 'perf probe' segfault when glob matching function without debuginfo (Wang Nan) - Remove newline char when reading event scale and unit (Madhavan Srinivasan) - Deal with kernel module names in '[]' correctly (Wang Nan) Infrastructure changes: - Fix the search for the kernel DSO on the unified list (Arnaldo Carvalho de Melo) - Move tools/perf/util/include/linux/{kernel.h,list.h,poison.h} to tools/include, to be used in tools/lib/bpf/ (Wang Nan) Signed-off-by:
-
- 03 Jun, 2015 1 commit
-
-
Wang Nan authored
Before patch ba92732e ('perf kmaps: Check kmaps to make code more robust'), 'perf report' and 'perf annotate' will segfault if trace data contains kernel module information like this: # perf report -D -i ./perf.data ... 0 0 0x188 [0x50]: PERF_RECORD_MMAP -1/0: [0xffffffbff1018000(0xf068000) @ 0]: x [test_module] ... # perf report -i ./perf.data --objdump=/path/to/objdump --kallsyms=/path/to/kallsyms perf: Segmentation fault -------- backtrace -------- /path/to/perf[0x503478] /lib64/libc.so.6(+0x3545f)[0x7fb201f3745f] /path/to/perf[0x499b56] /path/to/perf(dso__load_kallsyms+0x13c)[0x49b56c] /path/to/perf(dso__load+0x72e)[0x49c21e] /path/to/perf(map__load+0x6e)[0x4ae9ee] /path/to/perf(thread__find_addr_map+0x24c)[0x47deec] /path/to/perf(perf_event__preprocess_sample+0x88)[0x47e238] /path/to/perf[0x43ad02] /path/to/perf[0x4b55bc] /path/to/perf(ordered_events__flush+0xca)[0x4b57ea] /path/to/perf[0x4b1a01] /path/to/perf(perf_session__process_events+0x3be)[0x4b428e] /path/to/perf(cmd_report+0xf11)[0x43bfc1] /path/to/perf[0x474702] /path/to/perf(main+0x5f5)[0x42de95] /lib64/libc.so.6(__libc_start_main+0xf4)[0x7fb201f23bd4] /path/to/perf[0x42dfc4] This is because __kmod_path__parse treats '[' leading names as kernel name instead of names of kernel module. If perf.data contains build information and the buildid of such modules can be found, the dso->kernel of it will be set to DSO_TYPE_KERNEL by __event_process_build_id(), not kernel module. It will then be passed to dso__load() -> dso__load_kernel_sym() -> dso__load_kcore() if --kallsyms is provided. The refered patch adds NULL pointer checker to avoid segfault. However, such kernel modules are still processed incorrectly. This patch fixes __kmod_path__parse, makes it treat names like '[test_module]' as kernel modules. kmod-path.c is also update to reflect the above changes. Signed-off-by:
Wang Nan <wangnan0@huawei.com> Acked-by:
-
- 02 Jun, 2015 3 commits
-
-
Wang Nan authored
This patch moves list.h from tools/perf/util/include/linux/list.h to tools/include/linux/list.h to enable other libraries use macros in it, like libbpf which will be introduced by further patches. Since list.h depend on poison.h, poison.h is also moved. Both file use relative path, so one '..' is removed for each header to make them suit for new directory. MANIFEST is also updated for 'make perf-*-src-pkg'. Signed-off-by:
-
Wang Nan authored
This patch moves kernel.h from tools/perf/util/include/linux/kernel.h to tools/include/linux/kernel.h to enable other libraries use macros in it, like libbpf which will be introduced by further patches. MANIFEST is also updated for 'make perf-*-src-pkg'. Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Cc: Brendan Gregg <brendan.d.gregg@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: David Ahern <dsahern@gmail.com> Cc: He Kuang <hekuang@huawei.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kaixu Xia <xiakaixu@huawei.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Zefan Li <lizefan@huawei.com> Cc: pi3orama@163.com Link: http://lkml.kernel.org/r/1433144296-74992-2-git-send-email-wangnan0@huawei.com [ Fixed up the ifdef guard to match other entries in tools/include/linux ] Signed-off-by:
-
Arnaldo Carvalho de Melo authored
When unifying the user_dsos and kernel_dsos a bug was introduced by inverting the check for dso->kernel, fix it. Fixes: 3d39ac53 ("perf machine: No need to have two DSOs lists") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-xnrnq0kams3s2z9ek1wjb506@git.kernel.orgSigned-off-by:
-
- 01 Jun, 2015 1 commit
-
-
Madhavan Srinivasan authored
The <fd979c01> commit intruduced the perf_event_sysfs_show function to display the event_str value of an attr in kernel/event/core.c. But the function returns the value with a newline char. So, if a event also carries a event.unit file, when printing the counter data perf tool formatting goes for a spin. That is, because of the event unit, event name is printed in the newline because of perf_event_sysfs_show returns with a newline char. Now fixing perf core will break API, hencing proposing a fix in the perf tool. Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1433052383-21802-1-git-send-email-maddy@linux.vnet.ibm.com [ Add spaces around operators ] Signed-off-by:
-
- 30 May, 2015 1 commit
-
-
Wang Nan authored
Commit 4c859351 ("perf probe: Support glob wildcards for function name") introduces segfault problems when debuginfo is not available: # perf probe 'sys_w*' Added new events: Segmentation fault The first problem resides in find_probe_trace_events_from_map(). In that function, find_probe_functions() is called to match each symbol against glob to find the number of matching functions, but still use map__for_each_symbol_by_name() to find 'struct symbol' for matching functions. Unfortunately, map__for_each_symbol_by_name() does exact matching by searching in an rbtree. It doesn't know glob matching, and not easy for it to support it because it use rbtree based binary search, but we are unable to ensure all names matched by the glob (any glob passed by user) reside in one subtree. This patch drops map__for_each_symbol_by_name(). Since there is no rbtree again, re-matching all symbols costs a lot. This patch avoid it by saving all matching results into an array (syms). The second problem is the lost of tp->realname. In __add_probe_trace_events(), if pev->point.function is glob, the event name should be set to tev->point.realname. This patch ensures its existence by strdup sym->name instead of leaving a NULL pointer there. After this patch: # perf probe 'sys_w*' Added new events: probe:sys_waitid (on sys_w*) probe:sys_wait4 (on sys_w*) probe:sys_waitpid (on sys_w*) probe:sys_write (on sys_w*) probe:sys_writev (on sys_w*) You can now use it in all perf tools, such as: perf record -e probe:sys_writev -aR sleep 1 Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Zefan Li <lizefan@huawei.com> Link: http://lkml.kernel.org/r/1432892747-232506-1-git-send-email-wangnan0@huawei.comSigned-off-by:
-
- 29 May, 2015 7 commits
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: - Make Ctrl-C stop processing on TUI, allowing interrupting the load of big perf.data files (Namhyung Kim) - Fix 'perf annotate' -i option, which is currently ignored (Martin Liška) - Add ARM64 perf_regs_load to support libunwind and enable testing (Wang Nan) Infrastructure changes: - Fix thread ref-counting in db-export (Adrian Hunter) - Fix compiler warning about may be accessing uninitialized (Arnaldo Carvalho de Melo) - No need to have two lists for user and kernel DSOs, unify them (Arnaldo Carvalho de Melo) - Function namespace consistency fixups (Arnaldo Carvalho de Melo) - Do not fail on missing Build file, fixing the build on MIPS (Jiri Olsa) - Fix up syscall tests, making those tests pass on ARM64 (Riku Voipio) - Fix 'function unused' warning in 'perf probe' (Wang Nan) Signed-off-by:
-
Namhyung Kim authored
It was inconvenient that perf cannot be quit with SIGINT during processing samples on TUI especially for large data files. This was because the first argument of SLang_init_tty(), abort_char, being 0. The manual says it's the ascii value of the control character that will be used to generate the interrupt signal [1]. Passing -1 means to use the default value (Ctrl-C). However, after processing samples, Ctrl-C was used to in other cases as well - like stepping back from annotate. So recover the original behavior after processing. [1] http://jedsoft.org/slang/doc/html/cslang-6.html#ss6.1Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Jiri Olsa authored
Allow nesting into directories without Build file. Currently we force include of the Build file, which fails the build when the Build file is missing. We already support empty *-in.o' objects if there's nothing in the directory to be compiled, so we can just use it for missing Build file cases. Also adding this case under tests. Reported-by:
Rabin Vincent <rabin.vincent@axis.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
To make it consistent with the other dso lifetime routines. For instance: struct dso *vdso__new(struct machine *machine, const char *short_name, const char *long_name) Becomes: struct dso *machine__addnew_vdso(struct machine *machine, const char *short_name, const char *long_name) Because: 1) There is no 'struct vdso' for us to have vdso__ prefixed routines. 2) Because it will not really just create a new instance of 'struct dso', it'll call dso__new() but it will also insert it into the DSO's list/rbtree, and we have a method name for that: 'addnew', just like we have dsos__addnew(). 3) So it is really a 'struct machine' operation, it is the first argument, etc. This way the place where this is used gets consistent: if (vdso) { pgoff = 0; - dso = vdso__dso_findnew(machine, thread); + dso = machine__findnew_vdso(machine, thread); } else dso = machine__findnew_dso(machine, filename); Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-r3w3tvh8exm9xfz3p4tz9qbz@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
Similar to machine__findnew_thread(), also prepping for refcounting and locking, this time for struct dso instances. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/n/tip-fv3tshv5o1413coh147lszjc@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
We can, given a DSO, figure out if it is a kernel, a kernel module or a userlevel DSO, so stop having to process two lists in several functions. If searching becomes an issue at some point, we can have them in a rbtree, etc. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-s4yb0onpdywu6dj2xl9lxi4t@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
It never was a 'struct dso' method, so fix that by rename dso__kernel_findnew() to machine__findnew_kernel(). At some point I'll move it all to the machine.[ch] files, for now lets ease patch review by not moving too much stuff. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-zrxmblgsg5vx0iv4rhvq2f6l@git.kernel.orgSigned-off-by:
-
