Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp645224ybs; Sun, 24 May 2020 16:52:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxn8czM1hUVCcV+PanHXiu/ywTh7p/7cK7LPllzohGarrzYHsHYbmCfzAdhe/BMh5EkSlw1 X-Received: by 2002:a17:906:814b:: with SMTP id z11mr15849592ejw.531.1590364364715; Sun, 24 May 2020 16:52:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590364364; cv=none; d=google.com; s=arc-20160816; b=dl2pNwNnYSLQb1TwQLLpGTQPR8jpVCRS0ONxDxRfaT3Q7J+43qoydvPK+nbFvpovHV CGl5sAAk5baXc9oPTRYRo3Bux88IcpG94au+XAn/VRR5cNXqQSti/OAzLKGMLeH8rNBt RvX6k4sYl95TeuviBlcK8pzk7zcfXTUgeNxv3zRl2hVG5Gd2fLJZfHXa9KlT6inAX9bg XT2s2iEx4GOkaBCvZPyM4+eT8kIh2LxGGfRQbJ8zBdUPKadCIo1reJHhRcvcNmEk7tZg 1W6Ke9pURgU+97qK5pDXDsTou22LQUSgiiz7zpeWu/PCXnnob4IkMcr02/eV+v7QCAaZ bXOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=ESumRBe9TIyOOMkHD+jslTQBV+iCmU03AWMD85ZvEjg=; b=EDy/JFrpqIVHgDnMk6UaoNQQvtWLeesePi5DaGNtATYuPNpvd0epJ2l+P2VzD1CSUP O6qmGH3/rxC/qE7dbHzDOveF6CbhZcqITx+8NhARbRoJv18Vxui0tOPQLrypute+4pCH QOSPyTSwx6lshrYOerF9kQUHjPFFMwUa4Wh7crHB9AV7/a170k0wmpSduOzJyjzFSS8z UppVcU0ssGMhPDRxlwNXu0lI85SgNjwZYJ8rEc54T8+2pSOiG2W7ROUTwdk5bJ9y+GDE Nn5rk1DhQVHtxqKpxHi+OjX2d4Pbtj+Dt5DCfRoCIGxKbYHzWKju8SMaMrIWM3p1Fenv AaTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZMp4pKiQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z7si8273857ejf.749.2020.05.24.16.52.20; Sun, 24 May 2020 16:52:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZMp4pKiQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388303AbgEXXth (ORCPT + 99 others); Sun, 24 May 2020 19:49:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388124AbgEXXtg (ORCPT ); Sun, 24 May 2020 19:49:36 -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 52CFCC061A0E for ; Sun, 24 May 2020 16:49:36 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id r10so7924792pgv.8 for ; Sun, 24 May 2020 16:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ESumRBe9TIyOOMkHD+jslTQBV+iCmU03AWMD85ZvEjg=; b=ZMp4pKiQxLFMc7RHwEqUNBFQj6VkgRkIhbEBk4NDliCEsdRZ4GJv3a7HQx+GgIIrER 6eswjlvJD9zxF3iOoHIVvq5THVOxXiweB6YUx8BAL+aifCg7E67Q5MzXLZxHvuao0470 b7UffLco31BW55sJHVJSX1gr74znUzF6qWrm6wTHoJY03IDueAFK4MOEH00Nr+Zodbta CUcYywr7BIuJyL37YudlgKJ/QZWvLfsoTPQGmCsxW1UuZ/wKg2MIJ/d75ft2SItHIAPy +v4recEvB4y+WFhdvguxgRf3FI+HL30uiJA3mN3fzwDmzGbQoxPb8iCGK6lVtwOnSCdH 2ucQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ESumRBe9TIyOOMkHD+jslTQBV+iCmU03AWMD85ZvEjg=; b=cTAadTfMGz/ClZcIyvzhZw5sfiRoy2+RZYrQjC1jYt3Rw3WsIL89hZVvPoAYYL0GUo KsORHCyKMDqO8bxkRAnD33t35ApOnwOvG/Lue7O+Xnt4ZAG70C5s7SJYHdsQ5oSNGi3S EeQF6xrMxEuyolSRGOVtHVr81ARnmxhHCeXECnuQQ9SJCIKNgVl8kuHa+hmIimd7bTUN S1u+q2cj+ubps8XW7LGX9j7CrtogMHutwadsRQd70XRPVGESh7gu30p6mTNXR+R1v+Oj 7z9GeR/IpVMwsbrbfAtquA+eZSD3JBv7mDGxI2/XWXv5NKO8k8G6tXsoFuVe4gxg/mYP UVqw== X-Gm-Message-State: AOAM533uXDflsisucWrwTKS0DeQUKSRtpu62chDolkSQMOajmwqjPZ9u aYp2p5ZfMzsG+T3Fc4bcBbCD5A== X-Received: by 2002:a63:5f11:: with SMTP id t17mr23359768pgb.177.1590364175509; Sun, 24 May 2020 16:49:35 -0700 (PDT) Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id k4sm3628240pfp.173.2020.05.24.16.49.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 May 2020 16:49:34 -0700 (PDT) Date: Sun, 24 May 2020 16:49:31 -0700 From: Fangrui Song To: Arvind Sankar Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Nick Desaulniers , Dmitry Golovin , clang-built-linux@googlegroups.com, Ard Biesheuvel , Masahiro Yamada , Daniel Kiper , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] x86/boot: Add .text.startup to setup.ld Message-ID: <20200524234931.onovv64vjvrsfj33@google.com> References: <20200524212816.243139-2-nivedita@alum.mit.edu> <20200524221326.zo6zthdqecm2ke5t@google.com> <20200524230054.GA280334@rani.riverdale.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200524230054.GA280334@rani.riverdale.lan> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-24, Arvind Sankar wrote: >On Sun, May 24, 2020 at 03:13:26PM -0700, Fangrui Song wrote: >> On 2020-05-24, Arvind Sankar wrote: >> >gcc puts the main function into .text.startup when compiled with -Os (or >> >-O2). This results in arch/x86/boot/main.c having a .text.startup >> >section which is currently not included explicitly in the linker script >> >setup.ld in the same directory. >> > >> >The BFD linker places this orphan section immediately after .text, so >> >this still works. However, LLD git, since [1], is choosing to place it >> >immediately after the .bstext section instead (this is the first code >> >section). This plays havoc with the section layout that setup.elf >> >requires to create the setup header, for eg on 64-bit: >> > >> > LD arch/x86/boot/setup.elf >> > ld.lld: error: section .text.startup file range overlaps with .header >> > >>> .text.startup range is [0x200040, 0x2001FE] >> > >>> .header range is [0x2001EF, 0x20026B] >> > >> > ld.lld: error: section .header file range overlaps with .bsdata >> > >>> .header range is [0x2001EF, 0x20026B] >> > >>> .bsdata range is [0x2001FF, 0x200398] >> > >> > ld.lld: error: section .bsdata file range overlaps with .entrytext >> > >>> .bsdata range is [0x2001FF, 0x200398] >> > >>> .entrytext range is [0x20026C, 0x2002D3] >> > >> > ld.lld: error: section .text.startup virtual address range overlaps >> > with .header >> > >>> .text.startup range is [0x40, 0x1FE] >> > >>> .header range is [0x1EF, 0x26B] >> > >> > ld.lld: error: section .header virtual address range overlaps with >> > .bsdata >> > >>> .header range is [0x1EF, 0x26B] >> > >>> .bsdata range is [0x1FF, 0x398] >> > >> > ld.lld: error: section .bsdata virtual address range overlaps with >> > .entrytext >> > >>> .bsdata range is [0x1FF, 0x398] >> > >>> .entrytext range is [0x26C, 0x2D3] >> > >> > ld.lld: error: section .text.startup load address range overlaps with >> > .header >> > >>> .text.startup range is [0x40, 0x1FE] >> > >>> .header range is [0x1EF, 0x26B] >> > >> > ld.lld: error: section .header load address range overlaps with >> > .bsdata >> > >>> .header range is [0x1EF, 0x26B] >> > >>> .bsdata range is [0x1FF, 0x398] >> > >> > ld.lld: error: section .bsdata load address range overlaps with >> > .entrytext >> > >>> .bsdata range is [0x1FF, 0x398] >> > >>> .entrytext range is [0x26C, 0x2D3] >> > >> >Explicitly pull .text.startup into the .text output section to avoid >> >this. >> > >> >[1] https://reviews.llvm.org/D75225 >> > >> >Signed-off-by: Arvind Sankar >> >Reviewed-by: Fangrui Song >> >--- >> > arch/x86/boot/setup.ld | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> >diff --git a/arch/x86/boot/setup.ld b/arch/x86/boot/setup.ld >> >index 24c95522f231..ed60abcdb089 100644 >> >--- a/arch/x86/boot/setup.ld >> >+++ b/arch/x86/boot/setup.ld >> >@@ -20,7 +20,7 @@ SECTIONS >> > .initdata : { *(.initdata) } >> > __end_init = .; >> > >> >- .text : { *(.text) } >> >+ .text : { *(.text.startup) *(.text) } >> > .text32 : { *(.text32) } >> > >> > . = ALIGN(16); >> >-- >> >2.26.2 >> >> Should .text.startup* be used instead? If -ffunction-sections is used, >> >> // a.c >> int main() {} >> >> gcc -O2 a.c # .text.startup >> gcc -Os a.c # .text.startup >> >> gcc -O2 -ffunction-sections a.c # .text.startup.main >> gcc -Os -ffunction-sections a.c # .text.startup.main > >It's probably unlikely we'll use function-sections on the setup code, >but *(.text.*) might be more future-proof, since gcc/clang might grow >the ability to stick code into .text.hot or .text.unlikely etc >automatically. *(.text.*) looks good to me. When you send PATCH v2, feel free to add (There is indeed no guarantee that future clang FDO will not place it .text.unknown. :) Reviewed-by: Fangrui Song >> >> ----- >> >> In case anyone wants to CC a GCC dev for the citation that >> main compiles to `.text.startup` in -Os or -O2 mode, I have a small request >> that `.text.startup.` probably makes more sense. See >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095 >> >> I made an llvm change recently https://reviews.llvm.org/D79600