Message ID | 20230515005419.1293357-1-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 b10csp6591636vqo; Sun, 14 May 2023 18:22:19 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ40Nl6TBKWILHGlOrpVw0t4VJ/iVqMv0NYZLXvze+HLh9dyGx99TNGnC6g8tx+05sMlbCEw X-Received: by 2002:a05:6a20:2452:b0:103:558c:516 with SMTP id t18-20020a056a20245200b00103558c0516mr19879527pzc.55.1684113738991; Sun, 14 May 2023 18:22:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684113738; cv=none; d=google.com; s=arc-20160816; b=DF7CXrW6mnQQ56tqcOTI56lZdalWWTL/4p0+ndqZYnBxgYoWjEs/7AlNnOaumH0fn7 bTp0xhPxzF0OKGaFiuA+cTvTEwmmOdc39ju3d2hEvMQlDdQMCEl+PAulx8I7F5pHWKgd ErfyKaFP3OKjlQcIRkbxEtlfV6nuT8/AYK2V3Lp6/m2rGYZk4DyDkQBVi6Tl5L9DIi7e 50BodpdDBZOsPGMMTnZDckdreZxUdt0N1avhaHUoyVN9mCe4T3iRB8K0UqDxbmKByANG 9PtNioLCpLMXAE9AzwzkYVNug+psFxkBa93mXoBk9Lfa88i2XeFMOTs4Xh4K6XfOEgkW udPg== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=3zt+lMtc8hHNUVjxoBVpwhM8Iv4ZFY/2IHVWwyv7YZU=; b=dzyqPD7n0WO2FlgA/uyxlrZUARm7ZrydWXhWkNmKu+PcZ7vfvA5bM2zPHDuu4GlAh8 U9+oAnuNUaRF9c4VnkARBoldvvbPqhgMatmUzNsc9FJ+tY/k0HF7ngpfTdD54n3aiVA5 ewYpEWZQlm6VZ0BIdjQpO/Y51Kg4RRTW7scOebMbcFW6JGxZd8d7JvQT7ZTDB7Sz7UCD LLitsrD2QilmOe84M7HKdjcLxmcKHvYDXY/LQyg2tTTDlXIzt+0/hHiVZWpuHQ9LSEZl YRkrjuzt33/KfusOyoBDCzKOKNT35bAJplExnjNr4FGvLKSaJ+8d1v8dZgTXlN7vGM/Y cbCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hf+Ww+p1; 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 l197-20020a633ece000000b0051b9938a68esi14806101pga.128.2023.05.14.18.22.06; Sun, 14 May 2023 18:22:18 -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=hf+Ww+p1; 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 S229648AbjEOAyd (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Sun, 14 May 2023 20:54:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231829AbjEOAyc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 14 May 2023 20:54:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B0FA10DF; Sun, 14 May 2023 17:54:31 -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 AAE19618A8; Mon, 15 May 2023 00:54:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CE70C433D2; Mon, 15 May 2023 00:54:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684112070; bh=dK+m8ExSLg1/Xdbg8Lkb6eK8yh4H4j645K0PpXqtwRk=; h=From:To:Cc:Subject:Date:From; b=hf+Ww+p1WClDZHI/4UF0izLlInAGTiBLQg6t55k4T8s2QZU/eoHVGA59yJeUXjCyC +VU33v2wcqQP4xAsit+Cp7iqbYNhiz8BIR+BFyVRTAhhTlvGJ9z1yzTi0eg3Cgv0Fy uSjaOLP1RArGWfy7jBmkh2N6wD9zO1Fl5FhCH9e68fopxHysNjp3UEQ0uF15saOBk9 50wsr5/SmYp9dyIgH0UDRrfvvPWcuHMX9tkVzGZK6eA4FgmxzeA20RvkYX16uGifY/ MK2lpygFxAgoQoSGswijS26kqwXYrrV6rQqEyAaswRRrVGtXQWHqZ0a7eOm3pPuMAb yIOfI5JPL0RDg== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Russell King <linux@armlinux.org.uk>, Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, Sam Ravnborg <sam@ravnborg.org> Subject: [PATCH] modpost: fix section mismatch message for R_ARM_ABS32 Date: Mon, 15 May 2023 09:54:19 +0900 Message-Id: <20230515005419.1293357-1-masahiroy@kernel.org> X-Mailer: git-send-email 2.39.2 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?1765921247972945076?= X-GMAIL-MSGID: =?utf-8?q?1765921247972945076?= |
Series |
modpost: fix section mismatch message for R_ARM_ABS32
|
|
Commit Message
Masahiro Yamada
May 15, 2023, 12:54 a.m. UTC
The section mismatch check does not show proper warning messages for ARM.
Here, very simple test code.
#include <linux/init.h>
static int __initdata foo;
void set_foo(int x)
{
foo = x;
}
int get_foo(int x)
{
return foo;
}
If I compile it for ARM, modpost does not show the symbol name.
WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> (unknown) (section: .init.data)
WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data)
If I compile it for other architectures, modpost shows the correct symbol name.
WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> foo (section: .init.data)
WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data)
For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value.
arch/arm/kernel/module.c handles R_ARM_ABS32 as follows:
case R_ARM_ABS32:
case R_ARM_TARGET1:
*(u32 *)loc += sym->st_value;
I just mimicked it in modpost.
Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/mod/modpost.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On Sun, May 14, 2023 at 5:54 PM Masahiro Yamada <masahiroy@kernel.org> wrote: > > The section mismatch check does not show proper warning messages for ARM. > > Here, very simple test code. > > #include <linux/init.h> > > static int __initdata foo; > > void set_foo(int x) > { > foo = x; > } > > int get_foo(int x) > { > return foo; > } > > If I compile it for ARM, modpost does not show the symbol name. > > WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> (unknown) (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) > > If I compile it for other architectures, modpost shows the correct symbol name. > > WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> foo (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) > > For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. > > arch/arm/kernel/module.c handles R_ARM_ABS32 as follows: > > case R_ARM_ABS32: > case R_ARM_TARGET1: > *(u32 *)loc += sym->st_value; > > I just mimicked it in modpost. > > Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- > > scripts/mod/modpost.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > index d4531d09984d..c93780d93caf 100644 > --- a/scripts/mod/modpost.c > +++ b/scripts/mod/modpost.c > @@ -1460,12 +1460,13 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) > static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) > { > unsigned int r_typ = ELF_R_TYPE(r->r_info); > + unsigned int *location = reloc_location(elf, sechdr, r); If `location` is only used in one case of the switch, consider computing `location` only in that case. > + Elf_Sym *sym; > > switch (r_typ) { > case R_ARM_ABS32: > - /* From ARM ABI: (S + A) | T */ > - r->r_addend = (int)(long) > - (elf->symtab_start + ELF_R_SYM(r->r_info)); > + sym = elf->symtab_start + ELF_R_SYM(r->r_info); > + r->r_addend = TO_NATIVE(*location) + sym->st_value; > break; > case R_ARM_PC24: > case R_ARM_CALL: > -- > 2.39.2 >
On Thu, May 18, 2023 at 6:41 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Sun, May 14, 2023 at 5:54 PM Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > The section mismatch check does not show proper warning messages for ARM. > > > > Here, very simple test code. > > > > #include <linux/init.h> > > > > static int __initdata foo; > > > > void set_foo(int x) > > { > > foo = x; > > } > > > > int get_foo(int x) > > { > > return foo; > > } > > > > If I compile it for ARM, modpost does not show the symbol name. > > > > WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> (unknown) (section: .init.data) > > WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) > > > > If I compile it for other architectures, modpost shows the correct symbol name. > > > > WARNING: modpost: vmlinux.o: section mismatch in reference: set_foo (section: .text) -> foo (section: .init.data) > > WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) > > > > For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. > > > > arch/arm/kernel/module.c handles R_ARM_ABS32 as follows: > > > > case R_ARM_ABS32: > > case R_ARM_TARGET1: > > *(u32 *)loc += sym->st_value; > > > > I just mimicked it in modpost. > > > > Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > --- > > > > scripts/mod/modpost.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c > > index d4531d09984d..c93780d93caf 100644 > > --- a/scripts/mod/modpost.c > > +++ b/scripts/mod/modpost.c > > @@ -1460,12 +1460,13 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) > > static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) > > { > > unsigned int r_typ = ELF_R_TYPE(r->r_info); > > + unsigned int *location = reloc_location(elf, sechdr, r); > > If `location` is only used in one case of the switch, consider > computing `location` only in that case. I really suspect the other case labels are also wrong. For example, see R_ARM_PC24 in arch/arm/kernel/module.c The offset is encoded in the instruction. If you can compute the addend without reading the instruction, I do not know how. Anyway, I will fix another breakage. It will need 'location' as well. > > > + Elf_Sym *sym; > > > > switch (r_typ) { > > case R_ARM_ABS32: > > - /* From ARM ABI: (S + A) | T */ > > - r->r_addend = (int)(long) > > - (elf->symtab_start + ELF_R_SYM(r->r_info)); > > + sym = elf->symtab_start + ELF_R_SYM(r->r_info); > > + r->r_addend = TO_NATIVE(*location) + sym->st_value; > > break; > > case R_ARM_PC24: > > case R_ARM_CALL: > > -- > > 2.39.2 > > > > > -- > Thanks, > ~Nick Desaulniers
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index d4531d09984d..c93780d93caf 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1460,12 +1460,13 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) { unsigned int r_typ = ELF_R_TYPE(r->r_info); + unsigned int *location = reloc_location(elf, sechdr, r); + Elf_Sym *sym; switch (r_typ) { case R_ARM_ABS32: - /* From ARM ABI: (S + A) | T */ - r->r_addend = (int)(long) - (elf->symtab_start + ELF_R_SYM(r->r_info)); + sym = elf->symtab_start + ELF_R_SYM(r->r_info); + r->r_addend = TO_NATIVE(*location) + sym->st_value; break; case R_ARM_PC24: case R_ARM_CALL: