1. 19 Mar, 2018 2 commits
    • Jiri Olsa's avatar
      perf tools: Fix python extension build for gcc 8 · b7a313d8
      Jiri Olsa authored
      The gcc 8 compiler won't compile the python extension code with the
      following errors (one example):
      
        python.c:830:15: error: cast between incompatible  function types from              \
        ‘PyObject * (*)(struct pyrf_evsel *, PyObject *, PyObject *)’                       \
        uct _object * (*)(struct pyrf_evsel *, struct _object *, struct _object *)’} to     \
        ‘PyObject * (*)(PyObject *, PyObject *)’ {aka ‘struct _object * (*)(struct _objeuct \
        _object *)’} [-Werror=cast-function-type]
           .ml_meth  = (PyCFunction)pyrf_evsel__open,
      
      The problem with the PyMethodDef::ml_meth callback is that its type is
      determined based on the PyMethodDef::ml_flags value, which we set as
      METH_VARARGS | METH_KEYWORDS.
      
      That indicates that the callback is expecting an extra PyObject* arg, and is
      actually PyCFunctionWithKeywords type, but the base PyMethodDef::ml_meth type
      stays PyCFunction.
      
      Previous gccs did not find this, gcc8 now does. Fixing this by silencing this
      warning for python.c build.
      
      Commiter notes:
      
      Do not do that for CC=clang, as it breaks the build in some clang
      versions, like the ones in fedora up to fedora27:
      
        fedora:25:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option]
        fedora:26:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option]
        fedora:27:error: unknown warning option '-Wno-cast-function-type'; did you mean '-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option]
        #
      
      those have:
      
        clang version 3.9.1 (tags/RELEASE_391/final)
      
      The one in rawhide accepts that:
      
        clang version 6.0.0 (tags/RELEASE_600/final)
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Link: http://lkml.kernel.org/r/20180319082902.4518-2-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b7a313d8
    • Jiri Olsa's avatar
      perf tools: Fix snprint warnings for gcc 8 · 77f18153
      Jiri Olsa authored
      With gcc 8 we get new set of snprintf() warnings that breaks the
      compilation, one example:
      
        tests/mem.c: In function ‘check’:
        tests/mem.c:19:48: error: ‘%s’ directive output may be truncated writing \
              up to 99 bytes into a region of size 89 [-Werror=format-truncation=]
          snprintf(failure, sizeof failure, "unexpected %s", out);
      
      The gcc docs says:
      
       To avoid the warning either use a bigger buffer or handle the
       function's return value which indicates whether or not its output
       has been truncated.
      
      Given that all these warnings are harmless, because the code either
      properly fails due to uncomplete file path or we don't care for
      truncated output at all, I'm changing all those snprintf() calls to
      scnprintf(), which actually 'checks' for the snprint return value so the
      gcc stays silent.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Link: http://lkml.kernel.org/r/20180319082902.4518-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      77f18153
  2. 16 Mar, 2018 38 commits