From patchwork Thu Jun 25 18:47:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Nick Desaulniers X-Patchwork-Id: 191743 Delivered-To: patch@linaro.org Received: by 2002:a92:d244:0:0:0:0:0 with SMTP id v4csp1088448ilg; Thu, 25 Jun 2020 11:48:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxa9HX7lTLxWwYGSFp4j5S0RNJYkFAOPEjgWuabe2DQeRnhjj7Rb+sUNgz2ECqPn69XEInc X-Received: by 2002:a50:a207:: with SMTP id 7mr34507836edl.92.1593110930961; Thu, 25 Jun 2020 11:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593110930; cv=none; d=google.com; s=arc-20160816; b=DFw8EhpDj6wC34CrNugXrd0vUp2eDVIuqT5oU2p8rJ5eLeNdRgMnpYTcJZ8/lx8oJi wRn+yoGoiC8aEhb9Rn/BKYtiQiN+wLAZtIwXWAsWENcgO86xwYs7kd9cnwQ747BQf6Q1 lKWUDPlNPslE4m2qPBwoMOMO0g9sdNUlBDmnSowMhz0gF2e0vQpWrA9yxj6TefTFdg6X OR1Qh8m8dMvksxb6WDqeZl5+YgvZ4s94sPLqkYrhnfIzjUz9IQKOe9GAS7G3s+dH07xY W38aJCs7k9f625SSHbYQjqx/quLfzlj4E2G+UWStfIgJVTBiA9Wi1L/6G+gQv2AcsXju gvjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:from :subject:references:mime-version:message-id:in-reply-to:date :dkim-signature; bh=KSzIS4R7pLrhz4aCSES8O8YLNhHnwl2dEbCnP+qYXsc=; b=SuFCsPLQSJ6aakqkjpigKVgWM9iA7DQGhsNa3h6Q3w49YnsC27jqKfcHg6cr+Hc2as 9l3DweJTzPoJFfAVVXLw2CsSldn3zvUylOAfjUwVAtSVg4TkebvEQM1Y5mk0yrpMOGTk RYeKbT4waGcJc08OsP43zC/r8WqE0HJ5rfhQIKoII3uR5tKz3Su86mpgO5pbggbB1Diw 18P4thu54GWhczowVg+1OscuUUdeHm9174daMuQ3rKJWBq/LPBAByPXCkx8nl12aEaFv mf2KbsdI69yk/lC4xu6UMPg3FyPL+RPtbelYn4M1iOaXbo2g2vZOHsTnsdH68IzL3KVX Fp9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=knKRqtKF; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-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 f20si14833185ejx.646.2020.06.25.11.48.50; Thu, 25 Jun 2020 11:48:50 -0700 (PDT) Received-SPF: pass (google.com: domain of stable-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=knKRqtKF; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-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 S2390903AbgFYSsu (ORCPT + 15 others); Thu, 25 Jun 2020 14:48:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390007AbgFYSst (ORCPT ); Thu, 25 Jun 2020 14:48:49 -0400 Received: from mail-qv1-xf49.google.com (mail-qv1-xf49.google.com [IPv6:2607:f8b0:4864:20::f49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60F67C08C5C1 for ; Thu, 25 Jun 2020 11:48:49 -0700 (PDT) Received: by mail-qv1-xf49.google.com with SMTP id v20so4690265qvt.15 for ; Thu, 25 Jun 2020 11:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc:content-transfer-encoding; bh=KSzIS4R7pLrhz4aCSES8O8YLNhHnwl2dEbCnP+qYXsc=; b=knKRqtKFatSe2XltGnadadXYJpHZawUTiMMobs3BChNf5NM/0u4nk3w1QtVHi/2TGJ MGNBG0TtVcq9viEuR8zd0jqEo96IcfEx2gHSvdbcB3ckYEBrQpTXPq6tK7H3viZFPRCh W+tC3F45N6UTYj0fflhVzOdIoHvpOoyhbYthTQDmVfNUqHx0tGPh7vhaiXJwh7WiaksG 7Kf5IMLzUrlNU6YJQr6tdlMkp4qTejHrXN7RwXjbYezMfBQiMV6OqL4xP8Ruhg7l7wC+ 7t2aLAeRG5q6VH6HMvzX+Eg6XRp5dSUfVkt84VBZgheT20HcdfWZHWgyMfgVe44smHLm eYww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc:content-transfer-encoding; bh=KSzIS4R7pLrhz4aCSES8O8YLNhHnwl2dEbCnP+qYXsc=; b=LYDaDKVZdW8bu7UZwmwgOmIlYjFyum7LMBh63fIr6dtdCmzkC46jVEY0yFgQWC6edM oysb21gHMwS0dB8cHfOoOC3/RBSgOztrdp/8zGbEc+gGH9MIpJ+dyg5JgII5YI8eNhO+ Vujx4skL+mJoa9GN+N4FchFi+Xyb49Ws0hw8rK4j9o9TC2uZgaqRhYV0jMHcg2GaVJzG /IEwigFJBbVO0290RhH/o5F4BP9Ib2IdLV2bStdqjMIBu4DU9gngkq85oE7t73KXHJ3i f4yOpetJpcBFqShD1b9g7n/gGFwOhrck6TyHOw7bxinzH+7zfrzqzyZX//5EEs/JjGah ge7w== X-Gm-Message-State: AOAM530iLdkoxPq3ilcMOm5/MDV2sy322/nZuxHm8q8uHEBUPLJXiACv uWxZ/UF8Mf6ViRYcRRAwAVON0QwLsSALRcgWjRo= X-Received: by 2002:ad4:44a6:: with SMTP id n6mr2687847qvt.113.1593110928539; Thu, 25 Jun 2020 11:48:48 -0700 (PDT) Date: Thu, 25 Jun 2020 11:47:52 -0700 In-Reply-To: <20200622231536.7jcshis5mdn3vr54@google.com> Message-Id: <20200625184752.73095-1-ndesaulniers@google.com> Mime-Version: 1.0 References: <20200622231536.7jcshis5mdn3vr54@google.com> X-Mailer: git-send-email 2.27.0.111.gc72c7da667-goog Subject: [PATCH v2] vmlinux.lds: add PGO and AutoFDO input sections From: Nick Desaulniers To: Arnd Bergmann Cc: "=?UTF-8?q?F=C4=81ng-ru=C3=AC=20S=C3=B2ng?=" , Nick Desaulniers , stable@vger.kernel.org, Jian Cai , Luis Lozano , Manoj Gupta , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too. When compiling with profiling information (collected via PGO instrumentations or AutoFDO sampling), Clang will separate code into .text.hot, .text.unlikely, or .text.unknown sections based on profiling information. After D79600 (clang-11), these sections will have a trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown.. When using -ffunction-sections together with profiling infomation, either explicitly (FGKASLR) or implicitly (LTO), code may be placed in sections following the convention: .text.hot., .text.unlikely., .text.unknown. where , , and are functions. (This produces one section per function; we generally try to merge these all back via linker script so that we don't have 50k sections). For the above cases, we need to teach our linker scripts that such sections might exist and that we'd explicitly like them grouped together, otherwise we can wind up with code outside of the _stext/_etext boundaries that might not be mapped properly for some architectures, resulting in boot failures. If the linker script is not told about possible input sections, then where the section is placed as output is a heuristic-laiden mess that's non-portable between linkers (ie. BFD and LLD), and has resulted in many hard to debug bugs. Kees Cook is working on cleaning this up by adding --orphan-handling=warn linker flag used in ARCH=powerpc to additional architectures. In the case of linker scripts, borrowing from the Zen of Python: explicit is better than implicit. Also, ld.bfd's internal linker script considers .text.hot AND .text.hot.* to be part of .text, as well as .text.unlikely and .text.unlikely.*. I didn't see support for .text.unknown.*, and didn't see Clang producing such code in our kernel builds, but I see code in LLVM that can produce such section names if profiling information is missing. That may point to a larger issue with generating or collecting profiles, but I would much rather be safe and explicit than have to debug yet another issue related to orphan section placement. Cc: stable@vger.kernel.org Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655 Link: https://reviews.llvm.org/D79600 Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760 Reported-by: Jian Cai Debugged-by: Luis Lozano Suggested-by: Fāng-ruì Sòng Tested-by: Luis Lozano Tested-by: Manoj Gupta Signed-off-by: Nick Desaulniers --- Changes V1 -> V2: * Add .text.unknown.*. It's not strictly necessary for us yet, but I really worry that it could become a problem for us. Either way, I'm happy to drop for a V3, but I'm suggesting we not. * Beef up commit message. * Drop references to LLD; the LLVM change had nothing to do with LLD. I've realized I have a Pavlovian-response to changes from Fāng-ruì that I associate with LLD. I'm seeking professional help for my ailment. Forgive me. * Add link to now public CrOS bug. include/asm-generic/vmlinux.lds.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.27.0.111.gc72c7da667-goog diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index d7c7c7f36c4a..245c1af4c057 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -560,7 +560,10 @@ */ #define TEXT_TEXT \ ALIGN_FUNCTION(); \ - *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \ + *(.text.hot .text.hot.*) \ + *(TEXT_MAIN .text.fixup) \ + *(.text.unlikely .text.unlikely.*) \ + *(.text.unknown .text.unknown.*) \ NOINSTR_TEXT \ *(.text..refcount) \ *(.ref.text) \