From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387808AbgFXXkF (ORCPT ); Wed, 24 Jun 2020 19:40:05 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3AE8C061796 for ; Wed, 24 Jun 2020 16:40:05 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id e18so2300951pgn.7 for ; Wed, 24 Jun 2020 16:40:05 -0700 (PDT) Date: Wed, 24 Jun 2020 16:39:59 -0700 From: Sami Tolvanen Subject: Re: [PATCH 17/22] arm64: vdso: disable LTO Message-ID: <20200624233959.GB94769@google.com> References: <20200624203200.78870-1-samitolvanen@google.com> <20200624203200.78870-18-samitolvanen@google.com> <20200624215231.GC120457@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: Nick Desaulniers Cc: Masahiro Yamada , Will Deacon , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , clang-built-linux , Kernel Hardening , linux-arch , Linux ARM , Linux Kbuild mailing list , LKML , linux-pci@vger.kernel.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" On Wed, Jun 24, 2020 at 04:05:48PM -0700, Nick Desaulniers wrote: > On Wed, Jun 24, 2020 at 2:52 PM Sami Tolvanen wrote: > > > > On Wed, Jun 24, 2020 at 01:58:57PM -0700, 'Nick Desaulniers' via Clang Built Linux wrote: > > > On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote: > > > > > > > > Filter out CC_FLAGS_LTO for the vDSO. > > > > > > Just curious about this patch (and the following one for x86's vdso), > > > do you happen to recall specifically what the issues with the vdso's > > > are? > > > > I recall the compiler optimizing away functions at some point, but as > > LTO is not really needed in the vDSO, it's just easiest to disable it > > there. > > Sounds fishy; with extern linkage then I would think it's not safe to > eliminate functions. Probably unnecessary for the initial > implementation, and something we can follow up on, but always good to > have an answer to the inevitable question "why?" in the commit > message. Sure. I can test this again with the current toolchain to see if there are still problems. Sami