- 04 Aug, 2015 12 commits
-
-
Alexander Shishkin authored
Intel PT chapter in the new Intel Architecture SDM adds several packets corresponding enable bits and registers that control packet generation. Also, additional bits in the Intel PT CPUID leaf were added to enumerate presence and parameters of these new packets and features. The packets and enables are: * CYC: cycle accurate mode, provides the number of cycles elapsed since previous CYC packet; its presence and available threshold values are enumerated via CPUID; * MTC: mini time counter packets, used for tracking TSC time between full TSC packets; its presence and available resolution options are enumerated via CPUID; * PSB packet period is now configurable, available period values are enumerated via CPUID. This patch adds corresponding bit and register definitions, pmu driver capabilities based on CPUID enumeration, new attribute format bits for the new featurens and extends event configuration validation function to take these into account. Signed-off-by:Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: acme@infradead.org Cc: adrian.hunter@intel.com Cc: hpa@zytor.com Link: http://lkml.kernel.org/r/1438262131-12725-1-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Alexander Shishkin authored
Currently, the PT driver zeroes out the status register every time before starting the event. However, all the writable bits are already taken care of in pt_handle_status() function, except the new PacketByteCnt field, which in new versions of PT contains the number of packet bytes written since the last sync (PSB) packet. Zeroing it out before enabling PT forces a sync packet to be written. This means that, with the existing code, a sync packet (PSB and PSBEND, 18 bytes in total) will be generated every time a PT event is scheduled in. To avoid these unnecessary syncs and save a WRMSR in the fast path, this patch changes the default behavior to not clear PacketByteCnt field, so that the sync packets will be generated with the period specified as "psb_period" attribute config field. This has little impact on the trace data as the other packets that are normally sent within PSB+ (between PSB and PSBEND) have their own generation scenarios which do not depend on the sync packets. One exception where we do need to force PSB like this when tracing starts, so that the decoder has a clear sync point in the trace. For this purpose we aready have hw::itrace_started flag, which we are currently using to output PERF_RECORD_ITRACE_START. This patch moves setting itrace_started from perf core to the pmu::start, where it should still be 0 on the very first run. Signed-off-by:
-
Andy Lutomirski authored
The check looked wrong, although I think it was actually safe. TASK_SIZE is unnecessarily small for compat tasks, and it wasn't possible to make a range breakpoint so large it started in user space and ended in kernel space. Nonetheless, let's fix up the check for the benefit of future readers. A breakpoint is in the kernel if either end is in the kernel. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
Range breakpoints will do the wrong thing if the address isn't aligned. While we're there, add comments about why it's safe for instruction breakpoints. Signed-off-by:
-
Andy Lutomirski authored
Code on the kprobe blacklist doesn't want unexpected int3 exceptions. It probably doesn't want unexpected debug exceptions either. Be safe: disallow breakpoints in nokprobes code. On non-CONFIG_KPROBES kernels, there is no kprobe blacklist. In that case, disallow kernel breakpoints entirely. It will be particularly important to keep hw breakpoints out of the entry and NMI code once we move debug exceptions off the IST stack. Signed-off-by:
-
Kan Liang authored
AVG_LATENCY(bit 38) is only available on MSR_OFFCORE_RSP0. So the bit should be removed from RSP1 valid_mask. Since RSP0 and RSP1 may have different valid_mask, intel_alt_er should validate the config on the alternate offcore reg before replacing it. Signed-off-by:
Kan Liang <kan.liang@intel.com> Signed-off-by:
-
Alexander Shishkin authored
The x86_lbr_exclusive commit (48070342 "perf/x86: Mark Intel PT and LBR/BTS as mutually exclusive") mistakenly moved intel_pmu_needs_lbr_smpl() to perf_event.h, while another commit (a46a2300 "perf: Simplify the branch stack check") removed it in favor of needs_branch_stack(). This patch gets rid of intel_pmu_needs_lbr_smpl() for good. Signed-off-by:
-
Alexander Shishkin authored
Both intel_pmu_enable_bts() and intel_pmu_disable_bts() are in perf_event.h header file, no need to have them declared again in the driver. Signed-off-by:
-
Andi Kleen authored
Haswell and Broadwell have the same uncore CBOX/ARB PMU as Sandy Bridge. Add the respective model numbers to enable the SNB uncore PMU. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Andi Kleen authored
Add a new "ARB" uncore PMU that is used to monitor the uncore queue arbiter. This is useful to measure uncore queue occupancy and similar statistics. The registers all have the same format as the existing CBOX PMU. Also move the event constraints from the CBOX to ARB. The 0x80+ events are ARB events and cannot be scheduled on a CBOX PMU. Signed-off-by:
-
Vaishali Thakkar authored
The DEFINE_PCI_DEVICE_TABLE() macro is deprecated. Use 'struct pci_device_id' instead of DEFINE_PCI_DEVICE_TABLE(), with the goal of getting rid of this macro completely. This Coccinelle semantic patch performs this transformation: @@ identifier a; declarer name DEFINE_PCI_DEVICE_TABLE; initializer i; @@ - DEFINE_PCI_DEVICE_TABLE(a) + const struct pci_device_id a[] = i; Signed-off-by:
Vaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by:
-
Dasaratharaman Chandramouli authored
Knights Landing DRAM RAPL supports PKG and DRAM RAPL domains. DRAM RAPL has a different fixed energy unit (2^-16J) similar to that of HSW. Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> Signed-off-by:
Stephane Eranian <eranian@google.com> Acked-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jacob Pan Jun <jacob.jun.pan@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nikhil Rao <nikhil.rao@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/aa63b4a3af3160152fea1a10c807f4200527280c.1432665809.git.dasaratharaman.chandramouli@intel.comSigned-off-by:
-
- 31 Jul, 2015 17 commits
-
-
Oleg Nesterov authored
The xol_free_insn_slot()->waitqueue_active() check is buggy. We need mb() after we set the conditon for wait_event(), or xol_take_insn_slot() can miss the wakeup. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Pratyush Anand <panand@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20150721134036.GA4799@redhat.comSigned-off-by:
-
Oleg Nesterov authored
Change xol_add_vma() to use _install_special_mapping(), this way we can name the vma installed by uprobes. Currently it looks like private anonymous mapping, this is confusing and complicates the debugging. With this change /proc/$pid/maps reports "[uprobes]". As a side effect this will cause core dumps to include the XOL vma and I think this is good; this can help to debug the problem if the app crashed because it was probed. Signed-off-by:
-
Oleg Nesterov authored
install_special_mapping(pages) expects that "pages" is the zero- terminated array while xol_add_vma() passes &area->page, this means that special_mapping_fault() can wrongly use the next member in xol_area (vaddr) as "struct page *". Fortunately, this area is not expandable so pgoff != 0 isn't possible (modulo bugs in special_mapping_vmops), but still this does not look good. Signed-off-by:
-
Oleg Nesterov authored
The previous change documents that cleanup_return_instances() can't always detect the dead frames, the stack can grow. But there is one special case which imho worth fixing: arch_uretprobe_is_alive() can return true when the stack didn't actually grow, but the next "call" insn uses the already invalidated frame. Test-case: #include <stdio.h> #include <setjmp.h> jmp_buf jmp; int nr = 1024; void func_2(void) { if (--nr == 0) return; longjmp(jmp, 1); } void func_1(void) { setjmp(jmp); func_2(); } int main(void) { func_1(); return 0; } If you ret-probe func_1() and func_2() prepare_uretprobe() hits the MAX_URETPROBE_DEPTH limit and "return" from func_2() is not reported. When we know that the new call is not chained, we can do the more strict check. In this case "sp" points to the new ret-addr, so every frame which uses the same "sp" must be dead. The only complication is that arch_uretprobe_is_alive() needs to know was it chained or not, so we add the new RP_CHECK_CHAIN_CALL enum and change prepare_uretprobe() to pass RP_CHECK_CALL only if !chained. Note: arch_uretprobe_is_alive() could also re-read *sp and check if this word is still trampoline_vaddr. This could obviously improve the logic, but I would like to avoid another copy_from_user() especially in the case when we can't avoid the false "alive == T" positives. Tested-by:Pratyush Anand <panand@redhat.com> Signed-off-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Anton Arapov <arapov@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20150721134028.GA4786@redhat.comSigned-off-by:
-
Oleg Nesterov authored
arch/x86 doesn't care (so far), but as Pratyush Anand pointed out other architectures might want why arch_uretprobe_is_alive() was called and use different checks depending on the context. Add the new argument to distinguish 2 callers. Tested-by:
-
Oleg Nesterov authored
Change prepare_uretprobe() to flush the !arch_uretprobe_is_alive() return_instance's. This is not needed correctness-wise, but can help to avoid the failure caused by MAX_URETPROBE_DEPTH. Note: in this case arch_uretprobe_is_alive() can be false positive, the stack can grow after longjmp(). Unfortunately, the kernel can't 100% solve this problem, but see the next patch. Tested-by:
-
Oleg Nesterov authored
Test-case: #include <stdio.h> #include <setjmp.h> jmp_buf jmp; void func_2(void) { longjmp(jmp, 1); } void func_1(void) { if (setjmp(jmp)) return; func_2(); printf("ERR!! I am running on the caller's stack\n"); } int main(void) { func_1(); return 0; } fails if you probe func_1() and func_2() because handle_trampoline() assumes that the probed function should must return and hit the bp installed be prepare_uretprobe(). But in this case func_2() does not return, so when func_1() returns the kernel uses the no longer valid return_instance of func_2(). Change handle_trampoline() to unwind ->return_instances until we know that the next chain is alive or NULL, this ensures that the current chain is the last we need to report and free. Alternatively, every return_instance could use unique trampoline_vaddr, in this case we could use it as a key. And this could solve the problem with sigaltstack() automatically. But this approach needs more changes, and it puts the "hard" limit on MAX_URETPROBE_DEPTH. Plus it can not solve another problem partially fixed by the next patch. Note: this change has no effect on !x86, the arch-agnostic version of arch_uretprobe_is_alive() just returns "true". TODO: as documented by the previous change, arch_uretprobe_is_alive() can be fooled by sigaltstack/etc. Tested-by: -
Oleg Nesterov authored
Add the x86 specific version of arch_uretprobe_is_alive() helper. It returns true if the stack frame mangled by prepare_uretprobe() is still on stack. So if it returns false, we know that the probed function has already returned. We add the new return_instance->stack member and change the generic code to initialize it in prepare_uretprobe, but it should be equally useful for other architectures. TODO: this assumes that the probed application can't use multiple stacks (say sigaltstack). We will try to improve this logic later. Tested-by: -
Oleg Nesterov authored
Add the new "weak" helper, arch_uretprobe_is_alive(), used by the next patches. It should return true if this return_instance is still valid. The arch agnostic version just always returns true. The patch exports "struct return_instance" for the architectures which want to override this hook. We can also cleanup prepare_uretprobe() if we pass the new return_instance to arch_uretprobe_hijack_return_addr(). Tested-by:
-
Oleg Nesterov authored
No functional changes, preparation. Add the new helper, find_next_ret_chain(), which finds the first !chained entry and returns its ->next. Yes, it is suboptimal. We probably want to turn ->chained into ->start_of_this_chain pointer and avoid another loop. But this needs the boring changes in dup_utask(), so lets do this later. Change the main loop in handle_trampoline() to unwind the stack until ri is equal to the pointer returned by this new helper. Tested-by:
-
Oleg Nesterov authored
Turn the last pr_warn() in uprobes.c into uprobe_warn(). While at it: - s/kzalloc/kmalloc, we initialize every member of 'ri' - remove the pointless comment above the obvious code Tested-by:
-
Oleg Nesterov authored
1. It doesn't make sense to continue if handle_trampoline() fails, change handle_swbp() to always return after this call. 2. Turn pr_warn() into uprobe_warn(), and change handle_trampoline() to send SIGILL on failure. It is pointless to return to user mode with the corrupted instruction_pointer() which we can't restore. Tested-by:
-
Oleg Nesterov authored
We can simplify uprobe_free_utask() and handle_uretprobe_chain() if we add a simple helper which does put_uprobe/kfree and returns the ->next return_instance. Tested-by:
-
Oleg Nesterov authored
Cosmetic. Add the new trivial helper, get_uprobe(). It matches put_uprobe() we already have and we can simplify a couple of its users. Tested-by:
-
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: - Force period term to overload global settings, i.e. previously this command line: $ perf record -e 'cpu/instructions,period=20000/',cycles -c 1000 sleep 1 would result in both events having a period equal to 1000, with the fix we get something saner: $ perf evlist -v | grep period cpu/instructions,period=20000/: ... { sample_period, sample_freq }: 20000, ... cycles: ... { sample_period, sample_freq }: 1000 ... $ (Jiri Olsa) Infrastructure changes: - Use the dummy software event with freq=0 in the twatch.py python binding example, to avoid disabling nohz. (Arnaldo Carvalho de Melo) - Add some missing constants to the python binding. (Arnaldo Carvalho de Melo) - Fix mismatched declarations for elf_getphdrnum, that happens only in the corner case where this function is not found on the system. (Arnaldo Carvalho de Melo) - Add build test for having ending double slash. (Jiri Olsa) - Introduce callgraph_set for callgraph option. (Kan Liang) Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
Ingo Molnar authored
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: - Fix 'perf stat' transaction length metrics. (Andi Kleen) - Fix test build error when bindir contains double slash. (Pawel Moll) Signed-off-by:
-
- 30 Jul, 2015 1 commit
-
-
Jiri Olsa authored
Pawel Moll reported build issue for having extra slash (/) at the end of the prefix variable. $ make prefix=/usr/local/ CC tests/attr.o tests/attr.c: In function ‘test__attr’: tests/attr.c:168:50: error: expected ‘)’ before ‘;’ token snprintf(path_perf, PATH_MAX, "%s/perf", BINDIR); ^ tests/attr.c:176:1: error: expected ‘;’ before ‘}’ token } ^ tests/attr.c:176:1: error: control reaches end of non-void function [-Werror=return-type] } ^ cc1: all warnings being treated as errors Adding automated test case for this. Reported-by:Pawel Moll <pawel.moll@arm.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20150727182417.GD20509@krava.brq.redhat.comSigned-off-by:
-
- 29 Jul, 2015 9 commits
-
-
Kan Liang authored
Introduce callgraph_set to indicate whether the callgraph option was set by user. Signed-off-by:
-
Jiri Olsa authored
Currently the command line option settings beats the per event period settings: With no global settings, we get per-event configuration: $ perf record -e 'cpu/instructions,period=20000/' sleep 1 $ perf evlist -v ... { sample_period, sample_freq }: 20000 ... With 'c' option period setup, we get 'c' option value: $ perf record -e 'cpu/instructions,period=20000/' -c 1000 sleep 1 $ perf evlist -v ... { sample_period, sample_freq }: 1000 ... This patch makes the per-event settings overload the global 'c' option setup: $ perf record -e 'cpu/instructions,period=20000/' -c 1000 sleep 1 $ perf evlist -v ... { sample_period, sample_freq }: 20000 ... I think the making the per-event settings to overload any other config makes more sense than current state. However it breaks the current 'period' term handling, which might cause some noise.. so let's see ;-). Also fixing parse event tests with the new behaviour. Signed-off-by: -
Jiri Olsa authored
Add support to overload any global settings for event and force user specified term value. It will be useful for new time and backtrace terms. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
The semantic associated in tools/perf/ with foo__delete(instance) is to release all resources referenced by 'instance' members and then release the memory for 'instance' itself. The perf_session_env__delete() function isn't doing this, it just does the first part, but the space used by 'instance' itself isn't freed, as it is embedded in a larger structure, that will be freed at other stage. For these cases we se foo__exit(), i.e. the usage is: void foo__delete(foo) { if (foo) { foo__exit(foo); free(foo); } } But when we have something like: struct bar { struct foo foo; . . . } Then we can't really call foo__delete(&bar.foo), we must have this instead: void bar__exit(bar) { foo__exit(&bar.foo); /* free other bar-> resources */ } void bar__delete(bar) { if (bar) { bar__exit(bar); free(bar); } } So just rename perf_session_env__delete() to perf_session_env__exit(). Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-djbgpcfo5udqptx3q0flwtmk@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
When HAVE_ELF_GETPHDRNUM_SUPPORT is false we trip on this problem: CC /tmp/build/perf/util/symbol-elf.o util/symbol-elf.c:41:12: error: static declaration of ‘elf_getphdrnum’ follows non-static declaration static int elf_getphdrnum(Elf *elf, size_t *dst) ^ In file included from util/symbol.h:19:0, from util/symbol-elf.c:8: /usr/include/libelf.h:206:12: note: previous declaration of ‘elf_getphdrnum’ was here extern int elf_getphdrnum (Elf *__elf, size_t *__dst); ^ MKDIR /tmp/build/perf/bench/ /home/git/linux/tools/build/Makefile.build:68: recipe for target '/tmp/build/perf/util/symbol-elf.o' failed make[3]: *** [/tmp/build/perf/util/symbol-elf.o] Error 1 Fix it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.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-qcmekyfedmov4sxr0wahcikr@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
To not sample, what we want are just the PERF_RECORD_ lifetime events for threads, using the default, PERF_TYPE_HARDWARE + PERF_COUNT_HW_CYCLES and freq=1 (the default), makes perf reenable irq_vectors:local_timer_entry, disabling nohz, not good for some use cases where all we want is to get notifications when threads comes and goes... Fix it by using PERF_TYPE_SOFTWARE (no counter rotation) and PERF_COUNT_SW_DUMMY (created by Adrian so that we could have access to those PERF_RECORD_ goodies). Reported-by:
Luiz Fernando Capitulino <lcapitulino@redhat.com> Suggested-by:
-
Arnaldo Carvalho de Melo authored
Those were added to the kernel and tooling but we forgot to expose them via the python binding, fix it. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.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-sg1m6t2c58gchidfce4hmitg@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
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-ffuchgsbr5mqu91xl9oggfss@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
The python binding still doesn't provide symbol resolving facilities, but the recent addition of the trace_event__register_resolver() function made it add as a dependency the machine__resolve_kernel_addr() method, that in turn drags all the symbol resolving code. The problem: [root@zoo ~]# perf test -v python 17: Try 'import perf' in python, checking link problems : --- start --- test child forked, pid 6853 Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /tmp/build/perf/python/perf.so: undefined symbol: machine__resolve_kernel_addr test child finished with -1 ---- end ---- Try 'import perf' in python, checking link problems: FAILED! [root@zoo ~]# Fix it by requiring this function to receive the resolver as a parameter, just like pevent_register_function_resolver(), i.e. do not explicitely refer to an object file not included in tools/perf/util/python-ext-sources. [root@zoo ~]# perf test python 17: Try 'import perf' in python, checking link problems : Ok [root@zoo ~]# Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.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> Fixes: c3168b0d ("perf symbols: Provide libtraceevent callback to resolve kernel symbols") Link: http://lkml.kernel.org/n/tip-vxlhh95v2em9zdbgj3jm7xi5@git.kernel.orgSigned-off-by:
-
- 28 Jul, 2015 1 commit
-
-
Pawel Moll authored
When building with a prefix ending with a slash, for example: $ make prefix=/usr/local/ one of the perf tests fail to compile due to BUILD_STR macro mishandling bindir_SQ string containing with two slashes: -DBINDIR="BUILD_STR(/usr/local//bin)" with the following error: CC tests/attr.o tests/attr.c: In function ‘test__attr’: tests/attr.c:168:50: error: expected ‘)’ before ‘;’ token snprintf(path_perf, PATH_MAX, "%s/perf", BINDIR); ^ tests/attr.c:176:1: error: expected ‘;’ before ‘}’ token } ^ tests/attr.c:176:1: error: control reaches end of non-void function [-Werror=return-type] } ^ cc1: all warnings being treated as errors This patch works around the problem by "cleaning" the bindir string using make's abspath function. Signed-off-by:
-
