1. 20 10月, 2016 9 次提交
  2. 18 10月, 2016 21 次提交
  3. 17 10月, 2016 2 次提交
    • A
      perf jit: Fix build issue on Ubuntu · 53613e00
      Anton Blanchard 提交于
      When building on Ubuntu 16.04, I get the following error:
      
      Makefile:49: *** the openjdk development package appears to me missing, install and try again.  Stop.
      
      The problem is that update-java-alternatives has multiple spaces between
      fields, and cut treats each space as a new delimiter:
      
      java-1.8.0-openjdk-ppc64el     1081       /usr/lib/jvm/java-1.8.0-openjdk-ppc64el
      
      Fix this by using awk, which handles this fine.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Reviewed-by: NStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1476325243-15788-1-git-send-email-anton@ozlabs.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      53613e00
    • W
      perf jevents: Handle events including .c and .o · 2d470b62
      Wang Nan 提交于
      This patch helps with Sukadev's vendor event tree where such events can happen.
      
      >From Andi Kleen:
       Any event including a .c/.o/.bpf currently triggers BPF compilation or loading
       and then an error. This can happen for some Intel vendor events, which cannot
       be used.
      
      This patch fixes this problem by forbidding BPF file patch containing '{', '}'
      and ',', make sure flex consumes the leading '{', instead of matching it using
      a BPF file path.
      
      Tested result:
      
        $ perf stat -e '{unc_p_clockticks,unc_p_power_state_occupancy.cores_c0}' -a -I 1000
        invalid or unsupported event: '{unc_p_clockticks,unc_p_power_state_occupancy.cores_c0}'
        Run 'perf list' for a list of valid events
        (as expected, interperted as event)
      
        $ perf stat -e 'aaa.c' -a -I 1000
        ERROR: problems with path aaa.c: No such file or directory
        (as expected, interpreted as BPF source)
      
        $ perf stat -e 'aaa.ccc' -a -I 1000
        invalid or unsupported event: 'aaa.ccc'
        (as expected, interpreted as event)
      
        $ perf stat -e '{aaa.c}' -a -I 1000
        ERROR: problems with path aaa.c: No such file or directory
        event syntax error: '{aaa.c}'
        <SKIP>
        (as expected, interpreted as BPF source)
      
        $ perf stat -e '{cycles,aaa.c}' -a -I 1000
        ERROR: problems with path aaa.c: No such file or directory
        event syntax error: '{cycles,aaa.c}'
        (as expected, interpreted as BPF source)
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Reported-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1475900185-37967-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2d470b62
  4. 16 10月, 2016 2 次提交
    • J
      objtool: Skip all "unreachable instruction" warnings for gcov kernels · 9cfffb11
      Josh Poimboeuf 提交于
      Recently objtool has started reporting a few "unreachable instruction"
      warnings when CONFIG_GCOV is enabled for newer versions of GCC.  Usually
      this warning means there's some new control flow that objtool doesn't
      understand.  But in this case, objtool is correct and the instructions
      really are inaccessible.  It's an annoying quirk of gcov, but it's
      harmless, so it's ok to just silence the warnings.
      
      With older versions of GCC, it was relatively easy to detect
      gcov-specific instructions and to skip any unreachable warnings produced
      by them.  But GCC 6 has gotten craftier.
      
      Instead of continuing to play whack-a-mole with gcov, just use a bigger,
      more permanent hammer and disable unreachable warnings for the whole
      file when gcov is enabled.  This is fine to do because a) unreachable
      warnings are usually of questionable value; and b) gcov isn't used for
      production kernels and we can relax the checks a bit there.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      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>
      Link: http://lkml.kernel.org/r/38d5c87d61d9cd46486dd2c86f46603dff0df86f.1476393584.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9cfffb11
    • J
      objtool: Improve rare switch jump table pattern detection · 3732710f
      Josh Poimboeuf 提交于
      GCC 6 added a new switch statement jump table optimization which makes
      objtool's life harder.  It looks like:
      
        mov [rodata addr],%reg1
        ... some instructions ...
        jmpq *(%reg1,%reg2,8)
      
      The optimization is quite rare, but objtool still needs to be able to
      identify the pattern so that it can follow all possible control flow
      paths related to the switch statement.
      
      In order to detect the pattern, objtool starts from the indirect jump
      and scans backwards through the function until it finds the first
      instruction in the pattern.  If it encounters an unconditional jump
      along the way, it stops and considers the pattern to be not found.
      
      As it turns out, unconditional jumps can happen, as long as they are
      small forward jumps within the range being scanned.
      
      This fixes the following warnings:
      
        drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f4: sibling call from callable instruction with changed frame pointer
        drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      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>
      Link: http://lkml.kernel.org/r/8a9ed68ae1780e8d3963e4ee13f2f257fe3a3c33.1476393584.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3732710f
  5. 13 10月, 2016 2 次提交
  6. 12 10月, 2016 3 次提交
  7. 11 10月, 2016 1 次提交