Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4399232pxf; Tue, 23 Mar 2021 09:38:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3xIGycBKaY+t3jYLbBjTgm1MhFdnzKFMIMUoUVCeP3/jFqrPCAkc7OhL70QzpCfcg9ZXZ X-Received: by 2002:a17:906:8614:: with SMTP id o20mr5571127ejx.386.1616517501173; Tue, 23 Mar 2021 09:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616517501; cv=none; d=google.com; s=arc-20160816; b=JWuNrC5I0jLe1PyGCtKhfRHPjC7LHWRq07RRxLlNwKsSx+iiL3D9UCUgxC+5oPkoNb gviD74cD0VQcQ5QCKr6lsGEIzR1FOWsFc2rRNqnOJHgi7LkOIcJwo6k8csvISYLtP+d8 DH0wa+uSemZh78/Tv15+5vYONW/d/V7g8CJ+ziXbjOWtZTJgo1iWbXrWUvPcZNxrChtL cIO4CMbLQjlW48hGZVPelpPnKP8zeVv0N2QFC541Vy1XSOPQrpLE3zqIBavnkMGG3PBT 3aKnYKIyv/JAu1PJ6J+ztiWeZJ8M+eTInNd0C1/H4h+kN2sRwHvzQ5bNvg1kJ20wEH6a htNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Jr5FYe+pG7gGnI4NPChSWjNH7YK3vC58byQZ9zBCWWU=; b=PjNrv7sVwwgQJ8wkZQQnJlhvZvhA+xvBOFE2a+yQS16LeyTQQ/auEHyQB/gcIEhg9p jK8btvtFOdavCO1rOHQNjBeSlBvCiqZhAd4fXu9RBn3YW4oV+maZHihWOINKJTjbXmw4 QZSou77JY70hNS3mSqWESTIeOGo97xpodSCZAAnZGfVVK+ySoyMtzfEloYpEZYNjqBnU aO4IY1E560wn/DiERrpZWLojw93XIvxk2DyE0WV1wfpTGpdiMKvFI3RaPm9ljCgOlESd HStGrdcUjIUUFXJRiArZRPRQhQ+lFXG8RAZOvX44GXmIaqbwYuythqciobd016Ti0FqN KiSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="caAT+/Y9"; 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 qu2si13408679ejb.373.2021.03.23.09.37.58; Tue, 23 Mar 2021 09:38:21 -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="caAT+/Y9"; 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 S233320AbhCWQgb (ORCPT + 99 others); Tue, 23 Mar 2021 12:36:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233335AbhCWQg0 (ORCPT ); Tue, 23 Mar 2021 12:36:26 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08241C061763 for ; Tue, 23 Mar 2021 09:36:26 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id gb6so10335543pjb.0 for ; Tue, 23 Mar 2021 09:36:26 -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=Jr5FYe+pG7gGnI4NPChSWjNH7YK3vC58byQZ9zBCWWU=; b=caAT+/Y9z99z7OziYrIiQW7A6ptvfmUjhEbqmQZe0FcRaY9XV/8gPNXGbDmAG1rdvA 9k+70Y8IfxUHr/jvMlz6wPkyBvuV4G6m1LjGUy+aa5fK8oIKIkmlV3KU4XomXsbFkrhu Ztvi7Dajdxgx7c/Rz4jV6AuQV7gbrSM4hTOVp5MwX0hzujzuDozddcuO5jFXPwQZRk8T MYQCceXDwzEPlHdUy6DbvCAl6a/O7zH8RROqeSK+pmTQjkqkDalt9iYfaHusQ4f/F2sm QUtsQ+tuk7q5kaRpucPhtRY3PsiKVOnB62/6LJLARPX4iQYQoP45G/AUWUH3JS0Y3T3J S+IA== 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=Jr5FYe+pG7gGnI4NPChSWjNH7YK3vC58byQZ9zBCWWU=; b=GCBi/NaxXLgqYI4A0a/5mBjBPx9kuHuRYQRXim1e4CLIQvfejjdIDJ8yF9XT21hn8z wylBsrPDcZzytKVqW3Nl96M2i3gqChY+cne/eHyVqnUAJyQSshjBRYvLEGkBQd1bI9Gs q30UIsx02arqV25zRGlQVD6O+/beCa46SN0Czs8F4xgtVwnmMjKJUNUM8ZGMX15SwSiK 6cgLH7B3jK54j43m7FfVLrQMUwz1h2pvo1HheBoMnm61/sxQ5Q8vheUb2ebLGI2e5Wkd 3tZ+BL2XM6LQb8n8R0o9wuTb8Z1XG5P45kQ1Tnt/bYeDjW5GM1n/GINtfXqSYCt2lxhg zUwg== X-Gm-Message-State: AOAM531yjsPMoCaKmDYMC8O3IcoFidRu/9Xf0iiqfChXHti3KnfVkJ/0 2dgKyb+4j+Qx/caPe1z87/Tvgw== X-Received: by 2002:a17:90a:c087:: with SMTP id o7mr5353039pjs.38.1616517385469; Tue, 23 Mar 2021 09:36:25 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id c24sm17595799pfi.193.2021.03.23.09.36.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Mar 2021 09:36:24 -0700 (PDT) Date: Tue, 23 Mar 2021 16:36:21 +0000 From: Sean Christopherson To: Sami Tolvanen Cc: Masahiro Yamada , Michal Marek , Nathan Chancellor , Nick Desaulniers , linux-kbuild , LKML , clang-built-linux , Kees Cook Subject: Re: [PATCH] kbuild: Merge module sections if and only if CONFIG_LTO_CLANG is enabled Message-ID: References: <20210322234438.502582-1-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 23, 2021, Sami Tolvanen wrote: > On Mon, Mar 22, 2021 at 4:44 PM Sean Christopherson wrote: > > > > Merge module sections only when using Clang LTO. With gcc-10, merging > > sections does not appear to update the symbol tables for the module, > > e.g. 'readelf -s' shows the value that a symbol would have had, if > > sections were not merged. > > I'm fine with limiting this to LTO only, but it would be helpful to > understand which sections are actually getting merged here. It doesn't appear to matter which sections get merged, the tables only show the correct data if there is no merging whatsoever, e.g. allowing merging for any one of the four types (.bss, .data, .rodata and .text) results in breakage. AFAICT, merging any sections causes the layout to change and throw off the symbol tables. > Are you compiling the kernel with -ffunction-sections and/or -fdata-sections? I tried both. Default off, and forcing those flags by hacking the Makefile had no effect. > Does this issue only happen with gcc 10? gcc-7 shows the same behavior, I haven't checked anything older or anything in between.