[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKwvOd=F0_0RyjCzZKarbVXTsG+NfVdANF9mENHe7=8+LNc+Rw@mail.gmail.com>
Date: Tue, 22 Sep 2020 10:52:00 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Ian Bearman <Ian.Bearman@...rosoft.com>, rhadley@...rosoft.com
Cc: clang-built-linux <clang-built-linux@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v2 00/28] Add support for Clang LTO
On Tue, Sep 22, 2020 at 9:27 AM Ian Bearman <Ian.Bearman@...rosoft.com> wrote:
>
> Hi, Nick. Thanks for reaching out again. I'm excited to see other groups taking an interest in LTO and PGO for Linux. CFI for the kernel sounds like a huge deal, nice!
Yes, CFI is quite nice. There are some hardware extensions in the
works, but CFI has some additional coverage implemented in software.
That said, all new compiler technologies have bugs, and expose issues
in various code bases.
>
> I'd like to introduce you to @Russell Hadley. Russell wears a couple of hats right now, he's both the group manager for the MSVC code generation team as well as the (interim) team for the Linux tools team that i built and lead last year. He has inherited the various efforts my team was working on and is the right contact going forward to collaborate on Linux compiler and tools efforts.
Hey Russell, Ian,
Russel, Ian mentioned shipping LTO+PGO for a "downstream customer." I
assume they'd like to rebase at some point, so getting tweaks to the
build system upstream will help them lower their technical debt.
We're in the process of upstreaming LTO patches for Clang and would
love help collaborating on getting it working for GCC, too.
If you'd like to speak more about this virtually, we have our public
meeting every other week coming up tomorrow. It's noon pacific time,
see https://clangbuiltlinux.github.io/ for calendar invite and Google
meet link. Please stop by, even if it's just to say hello!
>
> ian Bearman
> Principal Software Engineering Manager
> Microsoft Visual C++ Team: ML Optimization & Code Generation
> #BlackLivesMatter
> /* Making your code faster, smaller, smarter! */
>
> -----Original Message-----
> From: Nick Desaulniers <ndesaulniers@...gle.com>
> Sent: Thursday, September 10, 2020 10:46 AM
> To: Ian Bearman <Ian.Bearman@...rosoft.com>
> Cc: clang-built-linux <clang-built-linux@...glegroups.com>; LKML <linux-kernel@...r.kernel.org>; Sami Tolvanen <samitolvanen@...gle.com>
> Subject: [EXTERNAL] Re: [PATCH v2 00/28] Add support for Clang LTO
>
> Hey Ian,
> It was nice to meet you at Linux plumbers. You might want to take a look at this series. It implements builds of the Linux kernel with LTO. It would be good to get eyes on it and help review it from folks working on this from the GCC angle. The series has some configs that split where Clang specific changes need to be made; it might be of interest to think about what would the similar changes be needed for GCC. Also, congrats on your LWN article!
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F830300%2F&data=02%7C01%7Cian.bearman%40microsoft.com%7C9adc842104f640d3ebb308d855b17221%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353568334933757&sdata=uM6%2BGj5z0gNAuIravVWOeVeIVsRI5YaPIJqB8qYsZ94%3D&reserved=0
>
> On Thu, Sep 3, 2020 at 1:30 PM Sami Tolvanen <samitolvanen@...gle.com> wrote:
> >
> > This patch series adds support for building x86_64 and arm64 kernels
> > with Clang's Link Time Optimization (LTO).
> >
> > In addition to performance, the primary motivation for LTO is to allow
> > Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google
> > has shipped millions of Pixel devices running three major kernel
> > versions with LTO+CFI since 2018.
> >
> > Most of the patches are build system changes for handling LLVM
> > bitcode, which Clang produces with LTO instead of ELF object files,
> > postponing ELF processing until a later stage, and ensuring initcall
> > ordering.
> >
> > Note that patches 1-4 are not directly related to LTO, but are needed
> > to compile LTO kernels with ToT Clang, so I'm including them in the
> > series for your convenience:
> >
> > - Patches 1-3 are required for building the kernel with ToT Clang,
> > and IAS, and patch 4 is needed to build allmodconfig with LTO.
> >
> > - Patches 3-4 are already in linux-next, but not yet in 5.9-rc.
> >
> > ---
> > Changes in v2:
> >
> > - Fixed -Wmissing-prototypes warnings with W=1.
> >
> > - Dropped cc-option from -fsplit-lto-unit and added .thinlto-cache
> > scrubbing to make distclean.
> >
> > - Added a comment about Clang >=11 being required.
> >
> > - Added a patch to disable LTO for the arm64 KVM nVHE code.
> >
> > - Disabled objtool's noinstr validation with LTO unless enabled.
> >
> > - Included Peter's proposed objtool mcount patch in the series
> > and replaced recordmcount with the objtool pass to avoid
> > whitelisting relocations that are not calls.
> >
> > - Updated several commit messages with better explanations.
> >
> >
> > Arvind Sankar (2):
> > x86/boot/compressed: Disable relocation relaxation
> > x86/asm: Replace __force_order with memory clobber
> >
> > Luca Stefani (1):
> > RAS/CEC: Fix cec_init() prototype
> >
> > Nick Desaulniers (1):
> > lib/string.c: implement stpcpy
> >
> > Peter Zijlstra (1):
> > objtool: Add a pass for generating __mcount_loc
> >
> > Sami Tolvanen (23):
> > objtool: Don't autodetect vmlinux.o
> > kbuild: add support for objtool mcount
> > x86, build: use objtool mcount
> > kbuild: add support for Clang LTO
> > kbuild: lto: fix module versioning
> > kbuild: lto: postpone objtool
> > kbuild: lto: limit inlining
> > kbuild: lto: merge module sections
> > kbuild: lto: remove duplicate dependencies from .mod files
> > init: lto: ensure initcall ordering
> > init: lto: fix PREL32 relocations
> > PCI: Fix PREL32 relocations for LTO
> > modpost: lto: strip .lto from module names
> > scripts/mod: disable LTO for empty.c
> > efi/libstub: disable LTO
> > drivers/misc/lkdtm: disable LTO for rodata.o
> > arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY
> > arm64: vdso: disable LTO
> > KVM: arm64: disable LTO for the nVHE directory
> > arm64: allow LTO_CLANG and THINLTO to be selected
> > x86, vdso: disable LTO only for vDSO
> > x86, relocs: Ignore L4_PAGE_OFFSET relocations
> > x86, build: allow LTO_CLANG and THINLTO to be selected
> >
> > .gitignore | 1 +
> > Makefile | 65 ++++++-
> > arch/Kconfig | 67 +++++++
> > arch/arm64/Kconfig | 2 +
> > arch/arm64/Makefile | 1 +
> > arch/arm64/kernel/vdso/Makefile | 4 +-
> > arch/arm64/kvm/hyp/nvhe/Makefile | 4 +-
> > arch/x86/Kconfig | 3 +
> > arch/x86/Makefile | 5 +
> > arch/x86/boot/compressed/Makefile | 2 +
> > arch/x86/boot/compressed/pgtable_64.c | 9 -
> > arch/x86/entry/vdso/Makefile | 5 +-
> > arch/x86/include/asm/special_insns.h | 28 +--
> > arch/x86/kernel/cpu/common.c | 4 +-
> > arch/x86/tools/relocs.c | 1 +
> > drivers/firmware/efi/libstub/Makefile | 2 +
> > drivers/misc/lkdtm/Makefile | 1 +
> > drivers/ras/cec.c | 9 +-
> > include/asm-generic/vmlinux.lds.h | 11 +-
> > include/linux/init.h | 79 +++++++-
> > include/linux/pci.h | 19 +-
> > kernel/trace/Kconfig | 5 +
> > lib/string.c | 24 +++
> > scripts/Makefile.build | 55 +++++-
> > scripts/Makefile.lib | 6 +-
> > scripts/Makefile.modfinal | 31 ++-
> > scripts/Makefile.modpost | 26 ++-
> > scripts/generate_initcall_order.pl | 270 ++++++++++++++++++++++++++
> > scripts/link-vmlinux.sh | 94 ++++++++-
> > scripts/mod/Makefile | 1 +
> > scripts/mod/modpost.c | 16 +-
> > scripts/mod/modpost.h | 9 +
> > scripts/mod/sumversion.c | 6 +-
> > scripts/module-lto.lds | 26 +++
> > tools/objtool/builtin-check.c | 13 +-
> > tools/objtool/builtin.h | 2 +-
> > tools/objtool/check.c | 83 ++++++++
> > tools/objtool/check.h | 1 +
> > tools/objtool/objtool.h | 1 +
> > 39 files changed, 883 insertions(+), 108 deletions(-) create mode
> > 100755 scripts/generate_initcall_order.pl
> > create mode 100644 scripts/module-lto.lds
> >
> >
> > base-commit: e28f0104343d0c132fa37f479870c9e43355fee4
> > --
> > 2.28.0.402.g5ffc5be6b7-goog
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists