From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26259C433EF for ; Fri, 29 Apr 2022 07:04:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MxqNXoounnynDu2wGiAHI+2cDlWFe4d/dQC/23MWeN4=; b=emvbHWKMdBRDnwOaEFXRTuvn5I UWFpPqTnkD/4N40KJp2HpsuCrUtB7MY4v7bI4xkxhJRegQym5IFyE7OGibon7COxKyOA/Ju6foHHM JfebZbvRZJWzv26DSHHv9EMZi3MgsPo/KIzvv0Zvk0BpUv+XgZ52T6Cf/uxYmhpWixU8msEnGgJtk F4niMdIca36p0ZvBEIJmyRWrQ8ESl/JDxXAm0wHVgC1gB43wTyhoO2mzIfkxfE5s7/EimM0mONg+y DHPwDQylXE4XPHCWgxCGUEZoNNfdT/luzqxcghvsazoTGIy8Oq0rvIpRt1iiB1RhQc2Yayqp1gEfS SNiEBV9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkKf7-009uSc-Da; Fri, 29 Apr 2022 07:03:33 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkKf3-009uQi-8R for linux-arm-kernel@lists.infradead.org; Fri, 29 Apr 2022 07:03:30 +0000 Received: by mail-pl1-x635.google.com with SMTP id n8so6401549plh.1 for ; Fri, 29 Apr 2022 00:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4wvnN7n76Q5CJ1km3GToxqpfStI18BwcbKOj3pGf1ac=; b=lvRQ0Ck1GcoMMUbPAGSFm+ibQTWWio6TIm3eYtFNdvIUH1QvvHJ5QruhAsqrS+MVqo IJeg+dzZw2K8YN3h0VpFsD2sYfTMQWajJqTPHNfwAbG6Q7wxJKqUFbmW8M1jxVRw4YZv WlyaJ+ud9pwKKsofQBrkjiSYXDPU719siTUysq6M9WJEEYzdm2Tpdjdi1+wZHTIQNA1w ikdA/J4HmrockxiMi+Y5N1sXCxsew1kzQptUcCvuKJ6ciw0zru84Kz9Dsf3DNFzSRu6M TMqMRh+7xKys1VdhVAu7b2cu3vEJBYuoHPhR7NG8wEhdwNKZALMRbCPa2JFwfvmCc5Sb uP/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4wvnN7n76Q5CJ1km3GToxqpfStI18BwcbKOj3pGf1ac=; b=aDDtk6OZEFPwox3e6Sm/SkoH20KBDvDd4scnJ/cw7ExgVE3D4bFRwnejNtHYRqDCIr ag7xm0EhRr9+sYy2F6YOJQwFvqe+h+WHi4Iv3xhlou+u+hbSRhA00C65RStaNDCQHZUB Vj5EgXm6BIZACt9YqjWc8AsbyF/Gejpn6f6Jovyns4dCz0cRd5HdIxNmr6/IN6VwjZiz LfA2TsKUAkgYFvWTknK8lK1yQ88Wyk0dkFIMmc7c2oLhnf1fM3scsMffSKB4p9K307ZP UnpniAmcK1iQYztZEXfHGoSSoFrRn94D8UMuYns0/Db8mxWc5zzVVeYcNsBFHs280c00 D62w== X-Gm-Message-State: AOAM530gujPBItUSsEhaUYSX9ROqwniZl44qUgXu37mKAayk7dc031QS 19jNkuW/EE/EftShbJu3RUqUOw== X-Google-Smtp-Source: ABdhPJwpIWiEI9KrjoXYz6/zJp6Pz/GIpGPJ14O0pNDCBGBampN5h7B7r6QcktF/o00eJqkbHC4ZgQ== X-Received: by 2002:a17:90b:4c47:b0:1d9:88b2:1995 with SMTP id np7-20020a17090b4c4700b001d988b21995mr2429772pjb.80.1651215802914; Fri, 29 Apr 2022 00:03:22 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:fb4f:b611:3fdd:bd70]) by smtp.gmail.com with ESMTPSA id s22-20020a17090a5d1600b001d954837197sm13228702pji.22.2022.04.29.00.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 00:03:22 -0700 (PDT) Date: Fri, 29 Apr 2022 00:03:18 -0700 From: Fangrui Song To: Ard Biesheuvel Cc: Nick Desaulniers , Linux ARM , clang-built-linux , Will Deacon , Catalin Marinas , Kees Cook , Mark Rutland , Nathan Chancellor , Sami Tolvanen Subject: Re: [RFC PATCH 2/2] arm64: kernel: switch to PIE code generation for relocatable kernels Message-ID: <20220429070318.iwj3j5lpfkw4t7g2@google.com> References: <20220427171241.2426592-1-ardb@kernel.org> <20220427171241.2426592-3-ardb@kernel.org> <20220428024030.gwxb746c5gwvcnw6@google.com> <20220428065742.rl3w5rz2ni2fhngl@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220429_000329_356626_4526FEE2 X-CRM114-Status: GOOD ( 20.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-04-28, Ard Biesheuvel wrote: >On Thu, 28 Apr 2022 at 20:53, Nick Desaulniers wrote: >> >> On Wed, Apr 27, 2022 at 11:57 PM Fangrui Song wrote: >> > >> > On 2022-04-28, Ard Biesheuvel wrote: >> > >On Thu, 28 Apr 2022 at 04:40, Fangrui Song wrote: >> > >> >> > >> On 2022-04-27, Ard Biesheuvel wrote: >> > >> >Fortunately, we can convince the compiler to handle this in a way that >> > >> >is a bit more suitable for freestanding binaries such as the kernel, by >> > >> >setting the 'hidden' visibility #pragma, which informs the compiler that >> > >> >symbol preemption or CoW footprint are of no concern to us, and so >> > >> >PC-relative references that are resolved at link time are perfectly >> > >> >fine. >> > >> >> > >> Agree >> > >> >> > > >> > >The only unfortunate thing is that -fvisibility=hidden does not give >> > >us the behavior we want, and we are forced to use the #pragma instead. >> > >> > Right. For a very long time there had been no option controlling the >> > access mode for undefined symbols (-fvisibility= is for defined >> > symbols). >> > >> > I added -fdirect-access-external-data to Clang which supports >> > many architectures (x86, aarch64, arm, riscv, ...). >> > GCC's x86 port added -mdirect-extern-access in 2022-02 (not available on aarch64). >> > >> > The use of `#pragma GCC visibility push(hidden)` looks good as a >> > portable solution. >> >> Portable, sure, which is fine for now. >> >> But there's just something about injecting a header into ever TU via >> -include in order to set a pragma and that there's such pragmas >> effecting codegen that makes my skin crawl. >> >> Perhaps we can come up with a formal feature request for toolchain >> vendors for an actual command line flag? >> >> Does the pragma have the same effect as >> `-fdirect-access-external-data`/`-mdirect-extern-access`, or wvisould >> this feature request look like yet another distinct flag? `#pragma GCC visibility push(hidden)` is very similar to -fvisibility=hidden -fdirect-access-external-data with Clang. In Clang there are only two differences: // TLS initial-exec model with -fdirect-access-external-data; // TLS local-exec model with `#pragma GCC visibility push(hidden)` extern __thread int var; int foo() { return var; } // hidden visibility suppresses -fno-plt. // -fdirect-access-external-data / GCC -mdirect-extern-access doesn't suppress -fno-plt. extern int bar(); int foo() { return bar() + 2; } The kernel uses neither TLS nor -fno-plt, so -fvisibility=hidden -fdirect-access-external-data can replace `#pragma GCC visibility push(hidden)`. >I agree that this is rather nasty. What I don't understand is why >-fvisibility=hidden gives different behavior to begin with, or why >-ffreestanding -fpie builds don't default to hidden visibility for >symbol declarations as well as definitions. -ffreestanding doesn't mean there is no DSO. A libc implementation (e.g. musl) may use -ffreestanding to avoid libc dependencies from the host environment. It may ship several shared objects and export multiple symbols. Implied -fvisibility=hidden will get in the way. There is a merit to make options orthogonal. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel