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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E157C433E0 for ; Sat, 1 Aug 2020 17:27:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D11C2072A for ; Sat, 1 Aug 2020 17:27:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lDrKUAaQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727784AbgHAR1u (ORCPT ); Sat, 1 Aug 2020 13:27:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726534AbgHAR1u (ORCPT ); Sat, 1 Aug 2020 13:27:50 -0400 Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEDC7C06174A; Sat, 1 Aug 2020 10:27:49 -0700 (PDT) Received: by mail-qv1-xf42.google.com with SMTP id j10so8896624qvo.13; Sat, 01 Aug 2020 10:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sH4ZgoE2+krh+pccRrSZUcqU9PhKP/eT8yH9LsNvEAE=; b=lDrKUAaQxNvYx4tI3nODZhJ8NcdsIkFV5oX3fhol8e4eN7e+SiVw939+t1R8UOsx01 NSBpVkU25zrVoic7dwx7vwPpt2Aoqluvpt9j57py3CrKQWNWRW/0ocBMD52snn+v8caX M5EIHqZBjgjmuY1sMynhvFwF9WFUnBJY9U/R0onHK6bADrVu5jsdfo7KQi7I+b3rmiyH I94kcHuWo7JSHfdbKTGM6SWqwPkurjVD4/oFL2UnQJjspmk2pVz1JyEb9FbK2c5RyjH8 e8Hlx4C+F+z+XQ3k78QRq/hE1RDG6ofkeYYFzko1A5R84bKXmrmY/eSIefXtxSAK4nDW K76Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=sH4ZgoE2+krh+pccRrSZUcqU9PhKP/eT8yH9LsNvEAE=; b=MTPYBAxVbM1E8LjLl+ZvzGea48iUR/V7PiezQ6Q6mmlYL8nDAZFHUuFdvTipXQsVB9 ftPFXn4YSQgwuGziioJnk3B2SCfvQ0RxCqaL4SzxTlZFN/4PsNjZBOSTTNONl44im0ZO fWQx8VJt3dHpL3eHmWpxvFaPv0KMpMw0xr1N5JLEj6oSmaBY67qk3hy3ZSHiIohninTi MxUPm5RmDUok5fDdUnpgR+Va2vRqMJsaHscR1N83TvgnRoV2v6DEghs/iHtggByZGwn1 df8kRCpkISIjqWW3WhHueN37jduN+B07IqBVwXo8cwkoMsIkol/jqniJC2cjgktJwhlv 9gag== X-Gm-Message-State: AOAM530AK+4zEsGiJFJCjSZGvpEtVGqo3tJDBP1hvo74Y3M6VcHvbFZm K2dkZRpuKmTx8fT0lkwFpvs= X-Google-Smtp-Source: ABdhPJzHOFdwhm3qJs8SrnZpWK+1UKvwkZdOAaQkwtzYxCu1nPpleYVo2pqxw+5n/1qFGKkbypbvDA== X-Received: by 2002:ad4:43c9:: with SMTP id o9mr9657897qvs.217.1596302868608; Sat, 01 Aug 2020 10:27:48 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id z197sm13658960qkb.66.2020.08.01.10.27.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2020 10:27:48 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Sat, 1 Aug 2020 13:27:46 -0400 To: Kees Cook Cc: Arvind Sankar , Thomas Gleixner , Will Deacon , Nick Desaulniers , Jian Cai , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Luis Lozano , Manoj Gupta , stable@vger.kernel.org, Catalin Marinas , Mark Rutland , Ard Biesheuvel , Peter Collingbourne , James Morse , Borislav Petkov , Ingo Molnar , Russell King , Masahiro Yamada , Nathan Chancellor , Arnd Bergmann , x86@kernel.org, clang-built-linux@googlegroups.com, linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andi Kleen , Michal Marek , Kristen Carlson Accardi Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Message-ID: <20200801172746.GC3249534@rani.riverdale.lan> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> <202007312237.4F385EB3@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202007312237.4F385EB3@keescook> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 31, 2020 at 11:18:02PM -0700, Kees Cook wrote: > On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > > > > This also changes the ordering to place all hot resp unlikely sections separate > > from other text, while currently it places the hot/unlikely bits of each file > > together with the rest of the code in that file. That seems like a reasonable > > Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the > input sections were entirely be ordered in compilation unit link order, > even in the case of orphan sections? (And I think either way, the answer > isn't the same between bfd and lld.) I actually thought the like-named > input sections were collected together first with lld, but bfd strictly > appended to the output section. I guess it's time for me to stare at -M > output from ld... I don't know what happened to the orphans previously. But .text.hot and .text.unlikely will now change ordering. It sounds from below like this wasn't intentional? Though it does seem to be how BFD's default linker scripts lay it out. > > Regardless, this patch is attempting to fix the problem where bfd and lld > lay out the orphans differently (as mentioned above, lld seems to sort > them in a way that is not strictly appended, and bfd seems to sort them > strictly appended). In the case of being appended to the .text output > section, this would cause boot failures due to _etext not covering the > resulting sections (which this[1] also encountered and fixed to be more > robust for such appended collection -- that series actually _depends_ on > orphan handling doing the appending, because there is no current way > to map wildcard input sections to their own separate output sections). > > > change and should be mentioned in the commit message. > > > > However, the history of their being together comes from > > > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > > > which seems to indicate there was some problem with having them separated out, > > although I don't quite understand what the issue was from the commit message. > > Looking at this again, I actually wonder if we have bigger issues here > with dead code elimination: > > #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION > #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* > ... > > that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown > but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, > I assume, why Clang switched to adding a trailing dot). However, this > patch lists .text.hot .text.hot.* first, so they'd get pulled to the > front correctly, but the trailing ones (with 2 dots) would not, since > they'd match the TEXT_MAIN wildcard first. (This problem actually existed > before this patch too, and is not the fault of 9bebe9e5b0f3, but rather > the addition of TEXT_MAIN, which could potentially match .text.unlikely > and .text.fixup) The existing comment on TEXT_TEXT mentions that issue. However, note that the dead code stuff is only available currently on mips and ppc, and is hidden behind EXPERT for those, so I'm not sure if anyone actually uses it. 9bebe9e5b0f3 predates LD_DEAD_CODE_DATA_ELIMINATION, and there were no wildcards I can see in .text at the time, which is why I don't understand what problem is referred to in the commit message. Btw, for the FGKASLR stuff, instead of keeping the output sections per function, couldn't you generate a table of functions with sizes, and use that when randomizing the order? Then the sections themselves could be collected into .text explicitly. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind Sankar Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Date: Sat, 1 Aug 2020 13:27:46 -0400 Message-ID: <20200801172746.GC3249534@rani.riverdale.lan> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> <202007312237.4F385EB3@keescook> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726534AbgHAR1u (ORCPT ); Sat, 1 Aug 2020 13:27:50 -0400 Content-Disposition: inline In-Reply-To: <202007312237.4F385EB3@keescook> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Arvind Sankar , Thomas Gleixner , Will Deacon , Nick Desaulniers , Jian Cai , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Luis Lozano , Manoj Gupta , stable@vger.kernel.org, Catalin Marinas , Mark Rutland , Ard Biesheuvel , Peter Collingbourne , James Morse , Borislav Petkov , Ingo Molnar , Russell King , Masahiro Yamada , Nathan Chancellor , Arnd Bergmann , x86@kernel.org On Fri, Jul 31, 2020 at 11:18:02PM -0700, Kees Cook wrote: > On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > > > > This also changes the ordering to place all hot resp unlikely sections separate > > from other text, while currently it places the hot/unlikely bits of each file > > together with the rest of the code in that file. That seems like a reasonable > > Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the > input sections were entirely be ordered in compilation unit link order, > even in the case of orphan sections? (And I think either way, the answer > isn't the same between bfd and lld.) I actually thought the like-named > input sections were collected together first with lld, but bfd strictly > appended to the output section. I guess it's time for me to stare at -M > output from ld... I don't know what happened to the orphans previously. But .text.hot and .text.unlikely will now change ordering. It sounds from below like this wasn't intentional? Though it does seem to be how BFD's default linker scripts lay it out. > > Regardless, this patch is attempting to fix the problem where bfd and lld > lay out the orphans differently (as mentioned above, lld seems to sort > them in a way that is not strictly appended, and bfd seems to sort them > strictly appended). In the case of being appended to the .text output > section, this would cause boot failures due to _etext not covering the > resulting sections (which this[1] also encountered and fixed to be more > robust for such appended collection -- that series actually _depends_ on > orphan handling doing the appending, because there is no current way > to map wildcard input sections to their own separate output sections). > > > change and should be mentioned in the commit message. > > > > However, the history of their being together comes from > > > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > > > which seems to indicate there was some problem with having them separated out, > > although I don't quite understand what the issue was from the commit message. > > Looking at this again, I actually wonder if we have bigger issues here > with dead code elimination: > > #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION > #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* > ... > > that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown > but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, > I assume, why Clang switched to adding a trailing dot). However, this > patch lists .text.hot .text.hot.* first, so they'd get pulled to the > front correctly, but the trailing ones (with 2 dots) would not, since > they'd match the TEXT_MAIN wildcard first. (This problem actually existed > before this patch too, and is not the fault of 9bebe9e5b0f3, but rather > the addition of TEXT_MAIN, which could potentially match .text.unlikely > and .text.fixup) The existing comment on TEXT_TEXT mentions that issue. However, note that the dead code stuff is only available currently on mips and ppc, and is hidden behind EXPERT for those, so I'm not sure if anyone actually uses it. 9bebe9e5b0f3 predates LD_DEAD_CODE_DATA_ELIMINATION, and there were no wildcards I can see in .text at the time, which is why I don't understand what problem is referred to in the commit message. Btw, for the FGKASLR stuff, instead of keeping the output sections per function, couldn't you generate a table of functions with sizes, and use that when randomizing the order? Then the sections themselves could be collected into .text explicitly. 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E28AAC433E0 for ; Sat, 1 Aug 2020 17:29:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AD96F2072A for ; Sat, 1 Aug 2020 17:29:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="b0S5HMyq"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lDrKUAaQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD96F2072A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:Date:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aU4UyTc/cButP17JU5xF7ezxfH5gp9+ubzcDNsuotzk=; b=b0S5HMyq337KwN8mWuGjTdP5H O5pVzG2l7XZ/rXEkzKOZqXVHS42L1G/OM5CIIQ9L3L8CyfvZQCgBBjF+IiqsjDQpyGfBc/uRc2rwa 0Oge5x/Fc7HAx7Du3LTcNoer7s0wSF+njk+mvATieTaueH2WGtY9o9niklzes3zKf70MxNdwgWfh4 ExeVz8NXP3gbGgiNUtRyhQZ++tv6RGMAivB/p1G8UQx3rWF7KsYZDZStDheSiV91cqwHNeHOXFscW kmgqiZf0DgGYL4uhBEtF4Lys1lnt+CBcs0OybYrFxs4ZA7hqZDYRI+vJA+KcQxvPwGM2rM9v9xsG4 kqz83mZEw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1vIX-00054H-Ba; Sat, 01 Aug 2020 17:27:53 +0000 Received: from mail-qv1-xf44.google.com ([2607:f8b0:4864:20::f44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1vIU-00053T-LW for linux-arm-kernel@lists.infradead.org; Sat, 01 Aug 2020 17:27:51 +0000 Received: by mail-qv1-xf44.google.com with SMTP id a19so9587418qvy.3 for ; Sat, 01 Aug 2020 10:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sH4ZgoE2+krh+pccRrSZUcqU9PhKP/eT8yH9LsNvEAE=; b=lDrKUAaQxNvYx4tI3nODZhJ8NcdsIkFV5oX3fhol8e4eN7e+SiVw939+t1R8UOsx01 NSBpVkU25zrVoic7dwx7vwPpt2Aoqluvpt9j57py3CrKQWNWRW/0ocBMD52snn+v8caX M5EIHqZBjgjmuY1sMynhvFwF9WFUnBJY9U/R0onHK6bADrVu5jsdfo7KQi7I+b3rmiyH I94kcHuWo7JSHfdbKTGM6SWqwPkurjVD4/oFL2UnQJjspmk2pVz1JyEb9FbK2c5RyjH8 e8Hlx4C+F+z+XQ3k78QRq/hE1RDG6ofkeYYFzko1A5R84bKXmrmY/eSIefXtxSAK4nDW K76Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=sH4ZgoE2+krh+pccRrSZUcqU9PhKP/eT8yH9LsNvEAE=; b=czKGsVScNbaE5+VQg/YQo2bqOgXgOGO5e8RIR7nlS7T2Q+vJcakzVeAnLk0P20qpti B0cpKyUAVjnbCk+KjEXTRY9qNciE9AkIe+XLaABwPZCPgyKg85TTAfHoqZYTXpuwAKIV P4YuQp+W/iYXE+yr6/wRFhvP5bYrEDG8m3S38tcE2WtbKJpH55TIBdvvW923J/RXkYVX FAWYXUkkZl4SiARWhpZOX7L8XLsGD/PerAJNTGMXezW6ouKki0d77cVSxbxEYNuspbk/ p0CT4mDEE3VFayXCqX+kIneu8KwzdRm+HTDUnMhpco+986nFAl+hiDyFnq7F5gzlJB+4 mK0Q== X-Gm-Message-State: AOAM5325Hrt//CixH3fOCg+2VHorXzlk+fsAP528wbVrTFhabQVSgNZC iBO55wEIbsixRC8XMuJ/dV0= X-Google-Smtp-Source: ABdhPJzHOFdwhm3qJs8SrnZpWK+1UKvwkZdOAaQkwtzYxCu1nPpleYVo2pqxw+5n/1qFGKkbypbvDA== X-Received: by 2002:ad4:43c9:: with SMTP id o9mr9657897qvs.217.1596302868608; Sat, 01 Aug 2020 10:27:48 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id z197sm13658960qkb.66.2020.08.01.10.27.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2020 10:27:48 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Sat, 1 Aug 2020 13:27:46 -0400 To: Kees Cook Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Message-ID: <20200801172746.GC3249534@rani.riverdale.lan> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-14-keescook@chromium.org> <20200801035128.GB2800311@rani.riverdale.lan> <202007312237.4F385EB3@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <202007312237.4F385EB3@keescook> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200801_132750_843739_D82BBD45 X-CRM114-Status: GOOD ( 34.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-efi@vger.kernel.org, Catalin Marinas , Arvind Sankar , Manoj Gupta , Kristen Carlson Accardi , Will Deacon , Thomas Gleixner , linux-arch@vger.kernel.org, Andi Kleen , =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= , Masahiro Yamada , x86@kernel.org, Russell King , Ard Biesheuvel , clang-built-linux@googlegroups.com, Ingo Molnar , Luis Lozano , Borislav Petkov , Arnd Bergmann , Jian Cai , Nathan Chancellor , Peter Collingbourne , linux-arm-kernel@lists.infradead.org, Michal Marek , Nick Desaulniers , linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Morse Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 31, 2020 at 11:18:02PM -0700, Kees Cook wrote: > On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > > > > This also changes the ordering to place all hot resp unlikely sections separate > > from other text, while currently it places the hot/unlikely bits of each file > > together with the rest of the code in that file. That seems like a reasonable > > Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the > input sections were entirely be ordered in compilation unit link order, > even in the case of orphan sections? (And I think either way, the answer > isn't the same between bfd and lld.) I actually thought the like-named > input sections were collected together first with lld, but bfd strictly > appended to the output section. I guess it's time for me to stare at -M > output from ld... I don't know what happened to the orphans previously. But .text.hot and .text.unlikely will now change ordering. It sounds from below like this wasn't intentional? Though it does seem to be how BFD's default linker scripts lay it out. > > Regardless, this patch is attempting to fix the problem where bfd and lld > lay out the orphans differently (as mentioned above, lld seems to sort > them in a way that is not strictly appended, and bfd seems to sort them > strictly appended). In the case of being appended to the .text output > section, this would cause boot failures due to _etext not covering the > resulting sections (which this[1] also encountered and fixed to be more > robust for such appended collection -- that series actually _depends_ on > orphan handling doing the appending, because there is no current way > to map wildcard input sections to their own separate output sections). > > > change and should be mentioned in the commit message. > > > > However, the history of their being together comes from > > > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > > > which seems to indicate there was some problem with having them separated out, > > although I don't quite understand what the issue was from the commit message. > > Looking at this again, I actually wonder if we have bigger issues here > with dead code elimination: > > #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION > #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* > ... > > that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown > but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, > I assume, why Clang switched to adding a trailing dot). However, this > patch lists .text.hot .text.hot.* first, so they'd get pulled to the > front correctly, but the trailing ones (with 2 dots) would not, since > they'd match the TEXT_MAIN wildcard first. (This problem actually existed > before this patch too, and is not the fault of 9bebe9e5b0f3, but rather > the addition of TEXT_MAIN, which could potentially match .text.unlikely > and .text.fixup) The existing comment on TEXT_TEXT mentions that issue. However, note that the dead code stuff is only available currently on mips and ppc, and is hidden behind EXPERT for those, so I'm not sure if anyone actually uses it. 9bebe9e5b0f3 predates LD_DEAD_CODE_DATA_ELIMINATION, and there were no wildcards I can see in .text at the time, which is why I don't understand what problem is referred to in the commit message. Btw, for the FGKASLR stuff, instead of keeping the output sections per function, couldn't you generate a table of functions with sizes, and use that when randomizing the order? Then the sections themselves could be collected into .text explicitly. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel