lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fUAjMxGDWfev_q6vKhe1M5D1UdXhPK6x5Y9bxUbrJ-tNw@mail.gmail.com>
Date:   Fri, 6 Mar 2020 08:47:51 -0800
From:   Ian Rogers <irogers@...gle.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Igor Lubashev <ilubashe@...mai.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Alexios Zavras <alexios.zavras@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wei Li <liwei391@...wei.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 1/3] tools: fix off-by 1 relative directory includes

On Fri, Mar 6, 2020 at 1:34 AM Jiri Olsa <jolsa@...hat.com> wrote:
>
> On Thu, Mar 05, 2020 at 11:11:08PM -0800, Ian Rogers wrote:
> > This is currently working due to extra include paths in the build.
>
> if you're fixing this, why not remove that extra include path then?

TL;DR it is complicated, but the include paths are all currently
necessary I believe and doing this way is necessary due to how header
files may be copied out of the kernel.

The current build uses multiple -Is to ensure the correct version of a
file is included, for example there are 27 files called bitops.h and
29 called bitsperlong.h. In
Google we're using libraries and bazel build files:
https://docs.bazel.build/versions/master/be/c-cpp.html#cc_library
and there's no way to say if you depend on this library then you need
this include path. We've tried to make perf this way but having tied
ourselves in knots we decided instead to emulate the include path
behaviour by rewriting includes when we import code using copybara:
https://github.com/google/copybara
We are able when doing this to prioritize the include paths we rewrite
so that a local directory version of a header is preferred over say
one in tools/lib/perf and perhaps tools/perf. Having full include
paths isn't really an option upstream as the same header file may be
copied into a libc project that has a different directory layout.
As we have absolute include paths at the time of building we need
relative include paths to be correct. Upstream -Is allow the build to
find the file but it is a bit of a quirk of the C preprocessor, so
fixing these off-by 1s feels like value add both for us and upstream.
For upstream to do anything different I think is going to be a
significant rewrite of how the Makefile build works and I'm not sure
what the result would look like.

Thanks!
Ian

> jirka
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ