Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp679829rwd; Thu, 1 Jun 2023 05:23:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4BDLvpROgkiL9CK2JtBCkCcHQHOliCKMlZZvJEcR9qMW6V5Y+LSPasj6Sx9aYcd0FLGcMR X-Received: by 2002:a05:6a21:32a2:b0:10d:5430:c8d6 with SMTP id yt34-20020a056a2132a200b0010d5430c8d6mr10274992pzb.0.1685622237194; Thu, 01 Jun 2023 05:23:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685622237; cv=none; d=google.com; s=arc-20160816; b=xcrGugVFo/7QadL8ZAkPSozBVitNneaif/YNV3PLjw52WK0J6HoZhgWj7il0r9n5mE 25YNASfd4F2NUs/gamJA+4gfi9YFN48omG6UjWC4I6nZ3twHKF6S/yysyhwaXEJzlVyk k9bYFYMeAt+G+SLWq3E6XuIGkRHKJ+fZvyuwGLLAKRDr8Dll1I4dHZOQF/2O6ogzGtka cIM2fAOgXJdmDWES+Yq7OMeTk5ZI9x+aJbCxSd2uoobWdLyGx0Sq6/voAwpgAzcv3Tsb DJVrcQ330SfxH3Np8IrqwCZoklu34lQO7z1haAiX0IVEZMcCST9RF9A8s2xJbwhhiSzJ zkTw== 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=5ljdHkPoU5MejoqBeV2J75M9dciUOY7wvi5BEm8GiXc=; b=Jp0oPMxtW0Gcuq7ApAA5KSAqfVrE+RHtl9gF2rP2fozTpNKgshoyZE83kREn8vuxun nG2M6mFoDeMAkF+4H4vA7NbNQikQewkz0dIGV1EU0NcRsiXuX4LVj09xYW7RisRtEGS1 RrXqCwJDN+eX6KGyHbqtZRZ5MKcUVMOXtHwR1HXRdQgJ5St9VpybVgZVQbKppN7/LHhb rO+Gu437WsApusJfczxKbPrAkMeBu9MvmxPfRei313+/bMteHcB9UsKJY3c7cI6RfNoS tSvAptz7O9kWUKAyzbkGWCpbSSTWSuWDzwhuQyFF6n5B7Wdx4n6TwtKCKslSyI1yNLnb mqBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dndPaLuh; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h129-20020a636c87000000b0053f01e23c47si2631064pgc.607.2023.06.01.05.23.43; Thu, 01 Jun 2023 05:23:57 -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=dndPaLuh; 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 S233252AbjFAMK1 (ORCPT + 99 others); Thu, 1 Jun 2023 08:10:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232354AbjFAMKY (ORCPT ); Thu, 1 Jun 2023 08:10:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BD9E9D; Thu, 1 Jun 2023 05:10:23 -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 08E6263AD1; Thu, 1 Jun 2023 12:10:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55101C433A0; Thu, 1 Jun 2023 12:10:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621422; bh=55J1SOTttemYkQioALMfaeUBYxrKSl0Zn4cIRDrkVGU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dndPaLuh9e+HMEwJ+Uk1OJvpmPjg4s25oxEMSJ1KuSM4fy8oEoacZZVcpsndxQUCz ICwcTH4nNkmN+pEObHcwbxr3urnb4XyNj4jdiIwFvifpNDph5ti5mCzeJ0OlvEzTaT n0WB5IbXLIp/BiQStZFKtHbtdjDB7NlEvRm19VBHyxwyD0SKJxl2xVkEYg0ajVyWF/ W7W+OuisE56taDpE3SLaWTJZV7DdDdGYPGC+uGn/YCid6cJPJUbTpDJeml5SUAY6Zp icewSeIoXae/2NS/4f6ehjkKpAXZCD+7P5Tgw9XWmhg64zfQoKWeUmAI0HrqRdjnes ccLksn7uCz5SA== From: Masahiro Yamada To: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, Russell King , Masahiro Yamada , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Sam Ravnborg Subject: [PATCH 1/7] modpost: fix section mismatch message for R_ARM_ABS32 Date: Thu, 1 Jun 2023 21:09:55 +0900 Message-Id: <20230601121001.1071533-2-masahiroy@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230601121001.1071533-1-masahiroy@kernel.org> References: <20230601121001.1071533-1-masahiroy@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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: X-Mailing-List: linux-kernel@vger.kernel.org addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. 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. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 : 0: e59f3004 ldr r3, [pc, #4] @ c 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 : 10: e59f3004 ldr r3, [pc, #4] @ 1c 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 7031e5da62e5..c68dad45ace2 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1094,6 +1094,10 @@ static Elf_Sym *find_tosym(struct elf_info *elf, Elf64_Sword addr, if (relsym->st_name != 0) return relsym; + /* + * Strive to find a better symbol name, but the resulting name may not + * match the symbol referenced in the original code. + */ relsym_secindex = get_secindex(elf, relsym); for (sym = elf->symtab_start; sym < elf->symtab_stop; sym++) { if (get_secindex(elf, sym) != relsym_secindex) @@ -1276,12 +1280,14 @@ 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); + Elf_Sym *sym = elf->symtab_start + ELF_R_SYM(r->r_info); + void *loc = reloc_location(elf, sechdr, r); + uint32_t inst; 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)); + inst = TO_NATIVE(*(uint32_t *)loc); + r->r_addend = inst + sym->st_value; break; case R_ARM_PC24: case R_ARM_CALL: -- 2.39.2