Message ID | 20230521160426.1881124-21-masahiroy@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp954326vqo; Sun, 21 May 2023 09:17:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7Bli75sva+OwAL8cToDkqTWAbf3/sxKXmDy/NAVZSlFB0eH50AJg6RyHy3g9d8Ayjv7ojO X-Received: by 2002:a05:6a20:6a1c:b0:100:9a80:2e90 with SMTP id p28-20020a056a206a1c00b001009a802e90mr9570418pzk.59.1684685832540; Sun, 21 May 2023 09:17:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684685832; cv=none; d=google.com; s=arc-20160816; b=p5hePOZI9Ln1y3szF4GNn08GKj8RtQ9XOv0I1E2C11hRb5XSfojaLvs1Hg0+XteYGK e44NVmML0ykJ8TzmC3PkHqr2Lq3yeiWNVfy1cSAZ/dqwVoWUR+b5RrgPS7xwi2i/I1Ja q0zRu6o6pIlsx8So4TGrCC1L4ZNHSS6TzLriKonDLF8yfIepSiekIr9z6Pu/gi47qLng rOf3P9ejGyQHxmZG61IiUYAkuZhFIOzWVeN+1SnBdjTlUhTP0wz4s8hlTN/4qFoEaErI 48zYIft0MexfuWsvoF9os+Q6xv+ay+k2sM1VVyExctQA6cKF/wSmEuzNT/tXXBsub+Wf lTsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=aZeGqTBhh39enLdgovXpuN6V3pBZU3gy1oMOi+LQ5QE=; b=y0ED3NbpheTafWLWpkYLBEQjjaexUsHcE4vhd/2iZgUbmmz1BHrZVesD3vsq52utj1 kV6PDEXiBK243oOCOlpEL4oqvydPMvYil+Ma6Uuk7ZiiSqVk01bWsDk9/zLf1D2yL6mI 5vxBPUUD6lFUxtueNhqIxxELhrwCjNr3vfCtN84JLKpBNZc2g0mUhXuuoNbMVR0VR/GW yTHTKnhJLBKURyc3m2PThCL4hxGTYrEYyUeIEbhwmtLEhaLDMxNZZWjE6BAERNRe7/KL xPeMnjnSNxBJ/vof1CK70jYEzaOlzCmBX/4RqdCtHapZHM0MdHi94TIEnBIGeRxhZnBG BhQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fuQmkKOb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b193-20020a6334ca000000b0053488d41c5asi285512pga.330.2023.05.21.09.16.58; Sun, 21 May 2023 09:17:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fuQmkKOb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230403AbjEUQHa (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Sun, 21 May 2023 12:07:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230487AbjEUQHP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 21 May 2023 12:07:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1ACC10C9; Sun, 21 May 2023 09:06:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E5DAB6150E; Sun, 21 May 2023 16:05:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5F73C4339C; Sun, 21 May 2023 16:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684685150; bh=yLNmLqnZjiVDJ1+11bIdJ/9gglrLgGpnva7MS4wZCMA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fuQmkKOb2ikon5r/q2qXFOV5oTZZS8XMuVYB/PsHRLP7PCSsjM0E+NeEa8UivuKmQ CnAxtt76X6Q5icdBf97JfxWVKmhiQro5JfTBzKP2CRasqalW6XLq3aR9SYOWg4cyX6 yrBimkCoAp3F31cJyfcQ+jW4ODLwBsH3e3VtpModseDbwsb5tjVLF2tZH6tk1v/b0q TqBVYxIe8uD5mbHSSv4cGsuFW1HaskwvAayHj8FTZPINe9MpmF30qq6HqhG04xuRUd pT58HZ9HRiqwxb5t/9a8cKQC4OHDk0uZRAhfja7MaFwYQyea7MhCcvO9/XTL78tzU7 p/ar05SiIS3tw== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada <masahiroy@kernel.org> Subject: [PATCH v6 20/20] modpost: show offset from symbol for section mismatch warnings Date: Mon, 22 May 2023 01:04:25 +0900 Message-Id: <20230521160426.1881124-21-masahiroy@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230521160426.1881124-1-masahiroy@kernel.org> References: <20230521160426.1881124-1-masahiroy@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766521131519567966?= X-GMAIL-MSGID: =?utf-8?q?1766521131519567966?= |
Series |
Unify <linux/export.h> and <asm/export.h>, remove EXPORT_DATA_SYMBOL(), faster TRIM_UNUSED_KSYMS
|
|
Commit Message
Masahiro Yamada
May 21, 2023, 4:04 p.m. UTC
Currently, modpost only shows the symbol names and section names, so it
repeats the same message if there are multiple relocations in the same
symbol. It is common the relocation spans across multiple instructions.
It is better to show the offset from the symbol.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/mod/modpost.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Sun, May 21, 2023 at 9:05 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > Currently, modpost only shows the symbol names and section names, so it > repeats the same message if there are multiple relocations in the same > symbol. It is common the relocation spans across multiple instructions. > > It is better to show the offset from the symbol. > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > scripts/mod/modpost.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index e7561fa57478..4da96746a03b 100644 > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -1135,8 +1135,8 @@ static void default_mismatch_handler(const char *modname, struct elf_info *elf, > > sec_mismatch_count++; > > - warn("%s: section mismatch in reference: %s (section: %s) -> %s (section: %s)\n", > - modname, fromsym, fromsec, tosym, tosec); > + warn("%s: section mismatch in reference: %s+0x%x (section: %s) -> %s (section: %s)\n", > + modname, fromsym, (unsigned int)(faddr - from->st_value), fromsec, tosym, tosec); Is the cast necessary if you use the %p format specifier instead of 0x%x? > > if (mismatch->mismatch == EXTABLE_TO_NON_TEXT) { > if (match(tosec, mismatch->bad_tosec)) > -- > 2.39.2 >
On Fri, May 26, 2023 at 3:27 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Sun, May 21, 2023 at 9:05 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > Currently, modpost only shows the symbol names and section names, so it > > repeats the same message if there are multiple relocations in the same > > symbol. It is common the relocation spans across multiple instructions. > > > > It is better to show the offset from the symbol. > > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > --- > > > > scripts/mod/modpost.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > > index e7561fa57478..4da96746a03b 100644 > > --- a/scripts/mod/modpost.c > > +++ b/scripts/mod/modpost.c > > @@ -1135,8 +1135,8 @@ static void default_mismatch_handler(const char *modname, struct elf_info *elf, > > > > sec_mismatch_count++; > > > > - warn("%s: section mismatch in reference: %s (section: %s) -> %s (section: %s)\n", > > - modname, fromsym, fromsec, tosym, tosec); > > + warn("%s: section mismatch in reference: %s+0x%x (section: %s) -> %s (section: %s)\n", > > + modname, fromsym, (unsigned int)(faddr - from->st_value), fromsec, tosym, tosec); > > Is the cast necessary if you use the %p format specifier instead of 0x%x? No. faddr and from->st_value are offsets from the start of the section. They are not pointers. %p does not make sense. > > > > > if (mismatch->mismatch == EXTABLE_TO_NON_TEXT) { > > if (match(tosec, mismatch->bad_tosec)) > > -- > > 2.39.2 > > > > > -- > Thanks, > ~Nick Desaulniers
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index e7561fa57478..4da96746a03b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1135,8 +1135,8 @@ static void default_mismatch_handler(const char *modname, struct elf_info *elf, sec_mismatch_count++; - warn("%s: section mismatch in reference: %s (section: %s) -> %s (section: %s)\n", - modname, fromsym, fromsec, tosym, tosec); + warn("%s: section mismatch in reference: %s+0x%x (section: %s) -> %s (section: %s)\n", + modname, fromsym, (unsigned int)(faddr - from->st_value), fromsec, tosym, tosec); if (mismatch->mismatch == EXTABLE_TO_NON_TEXT) { if (match(tosec, mismatch->bad_tosec))