[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0AyciKoHzrgtaLxP9boo8WqZCe8YfPBzGPQ14PW_2KgQ@mail.gmail.com>
Date: Tue, 8 Dec 2020 14:54:28 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Sami Tolvanen <samitolvanen@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Will Deacon <will@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-arch <linux-arch@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-pci <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v8 00/16] Add support for Clang LTO
On Tue, Dec 8, 2020 at 1:15 PM Arnd Bergmann <arnd@...nel.org> wrote:
> On Tue, Dec 1, 2020 at 10:37 PM 'Sami Tolvanen' via Clang Built Linux <clang-built-linux@...glegroups.com> wrote:
>
> - many builds complain about thousands of duplicate symbols in the kernel, e.g.
> ld.lld: error: duplicate symbol: qrtr_endpoint_post
> >>> defined in net/qrtr/qrtr.lto.o
> >>> defined in net/qrtr/qrtr.o
> ld.lld: error: duplicate symbol: init_module
> >>> defined in crypto/842.lto.o
> >>> defined in crypto/842.o
> ld.lld: error: duplicate symbol: init_module
> >>> defined in net/netfilter/nfnetlink_log.lto.o
> >>> defined in net/netfilter/nfnetlink_log.o
> ld.lld: error: duplicate symbol: vli_from_be64
> >>> defined in crypto/ecc.lto.o
> >>> defined in crypto/ecc.o
> ld.lld: error: duplicate symbol: __mod_of__plldig_clk_id_device_table
> >>> defined in drivers/clk/clk-plldig.lto.o
> >>> defined in drivers/clk/clk-plldig.o
A small update here: I see this behavior with every single module
build, including 'tinyconfig' with one module enabled, and 'defconfig'.
I tuned the randconfig setting using KCONFIG_PROBABILITY=2:2:1
now, which only enables a few symbols. With this I see faster build
times (obvioulsy), aroudn 30 seconds per kernel, and all small builds
with CONFIG_MODULES disabled so far succeed.
It appears that the problems I saw originally only happen for larger
configurations, or possibly a combination of Kconfig options that don't
happen that often on randconfig builds with low
KCONFIG_PROBABILITY.
Arnd
Powered by blists - more mailing lists