From patchwork Thu Jun 1 12:09:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263611 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4BB9C7EE29 for ; Thu, 1 Jun 2023 12:10:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232823AbjFAMK0 (ORCPT ); Thu, 1 Jun 2023 08:10:26 -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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@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: From patchwork Thu Jun 1 12:09:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263612 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54BD4C7EE29 for ; Thu, 1 Jun 2023 12:10:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233239AbjFAMK3 (ORCPT ); Thu, 1 Jun 2023 08:10:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233247AbjFAMK0 (ORCPT ); Thu, 1 Jun 2023 08:10:26 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF6F3D7; Thu, 1 Jun 2023 05:10:25 -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 8BFA6637B9; Thu, 1 Jun 2023 12:10:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDFB2C433EF; Thu, 1 Jun 2023 12:10:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621425; bh=PEcdZVhDuhBQ+xzAg//irJiyn8poLhX+cHlMc0n1u9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AceQvPqRM3KtwlgBB5UkRQbl23xq46V7w8u3OwmU6aIrg9u2A62nZGZqxv9Gxn3/j sUDJgsIcdKhl0IHak3JXYxLL0pi2bIvIBu6f+2wk3Z/GvE3ZCraPlnKp9pDbblONYI /ZTpP312891+mBwMGF3SvOAp19x9RJkGSHP+umt4j2eP4iaqTbQv9VIX90mY9w4MPv DRiPoIRK+RenTigsgxon9ZuF38xV/MyW5xwBCpmggPwQZMdzX7VnM9Og0A2neWmHwu W7XOmmrJoabLtV2kTGz2QCfsDBvatNbG8XVKoPxoyOI3yc+ryRtL/Y6RLa60LoWn2g MW62ColJsDfWQ== 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 , Russell King , Rusty Russell , Sam Ravnborg , Tony Lindgren Subject: [PATCH 2/7] modpost: fix section mismatch message for R_ARM_{PC24,CALL,JUMP24} Date: Thu, 1 Jun 2023 21:09:56 +0900 Message-Id: <20230601121001.1071533-3-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a wrong way. Here, test code. [test code for R_ARM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with ARM multi_v7_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I imported (with adjustment) sign_extend32() from include/linux/bitops.h. The '+8' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Fixes: 6e2e340b59d2 ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers") Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index c68dad45ace2..e47bba7cfad2 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1277,12 +1277,20 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) #define R_ARM_THM_JUMP19 51 #endif +static int32_t sign_extend32(int32_t value, int index) +{ + uint8_t shift = 31 - index; + + return (int32_t)(value << shift) >> shift; +} + 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; + int32_t offset; switch (r_typ) { case R_ARM_ABS32: @@ -1292,6 +1300,10 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) case R_ARM_PC24: case R_ARM_CALL: case R_ARM_JUMP24: + inst = TO_NATIVE(*(uint32_t *)loc); + offset = sign_extend32((inst & 0x00ffffff) << 2, 25); + r->r_addend = offset + sym->st_value + 8; + break; case R_ARM_THM_CALL: case R_ARM_THM_JUMP24: case R_ARM_THM_JUMP19: From patchwork Thu Jun 1 12:09:57 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263613 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65C55C77B7A for ; Thu, 1 Jun 2023 12:10:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233277AbjFAMKa (ORCPT ); Thu, 1 Jun 2023 08:10:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233266AbjFAMK3 (ORCPT ); Thu, 1 Jun 2023 08:10:29 -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 2CD32FC; Thu, 1 Jun 2023 05:10:28 -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 B6B4463AD1; Thu, 1 Jun 2023 12:10:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6299FC433A0; Thu, 1 Jun 2023 12:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621427; bh=l8pAEKo80YCNxNTbkTmM13VW7qxFsKV/QhE7nwuJWrQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KrhuaH7LZ/RQ/+MSwWzLiNquVNkd0wGhx/fRtIGdvLCiXXpQqO2FqmGhcSWZXYD1C FIGbKvip4KGcAUy48afS7bWi3lsEKbIf1OedIGJKxtK441R00ObOih5QJnDOpWiFnf LaZzKgcngiLE0AKqyN7xALGJWRlEQ790MDueiPj6itTFSTpBnOE8Lx5nnKSqh/2lpb Nnq5CrlxdbfQoXLODJdV6mQOhNlUsZTwrmSCwrTh9vQIMrnS7lVAbhR76z+dopkW7j IVT7pjpIOUaS8kPmMYR9GplggmIeUn9NeMJiKDIxuyuzAWT9zdprm09VicLdOO8lkv 6T+yeXs8xDLbw== 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 Subject: [PATCH 3/7] modpost: detect section mismatch for R_ARM_{MOVW_ABS_NC,MOVT_ABS} Date: Thu, 1 Jun 2023 21:09:57 +0900 Message-Id: <20230601121001.1071533-4-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org For ARM defconfig (i.e. multi_v7_defconfig), modpost fails to detect some types of section mismatches. [test code] #include int __initdata foo; int get_foo(void) { return foo; } It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.text' at offset 0x200 contains 2 entries: Offset Info Type Sym.Value Sym. Name 00000000 0000062b R_ARM_MOVW_ABS_NC 00000000 .LANCHOR0 00000004 0000062c R_ARM_MOVT_ABS 00000000 .LANCHOR0 Currently, R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS are just skipped. Add code to handle them. I checked arch/arm/kernel/module.c to learn how the offset is encoded in the instruction. The referenced symbol in relocation might be a local anchor. If is_valid_name() returns false, let's search for a better symbol name. Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index e47bba7cfad2..5a5e802b160c 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1078,7 +1078,7 @@ static inline int is_valid_name(struct elf_info *elf, Elf_Sym *sym) /** * Find symbol based on relocation record info. * In some cases the symbol supplied is a valid symbol so - * return refsym. If st_name != 0 we assume this is a valid symbol. + * return refsym. If is_valid_name() == true, we assume this is a valid symbol. * In other cases the symbol needs to be looked up in the symbol table * based on section and address. * **/ @@ -1091,7 +1091,7 @@ static Elf_Sym *find_tosym(struct elf_info *elf, Elf64_Sword addr, Elf64_Sword d; unsigned int relsym_secindex; - if (relsym->st_name != 0) + if (is_valid_name(elf, relsym)) return relsym; /* @@ -1297,6 +1297,13 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) inst = TO_NATIVE(*(uint32_t *)loc); r->r_addend = inst + sym->st_value; break; + case R_ARM_MOVW_ABS_NC: + case R_ARM_MOVT_ABS: + inst = TO_NATIVE(*(uint32_t *)loc); + offset = sign_extend32(((inst & 0xf0000) >> 4) | (inst & 0xfff), + 15); + r->r_addend = offset + sym->st_value; + break; case R_ARM_PC24: case R_ARM_CALL: case R_ARM_JUMP24: From patchwork Thu Jun 1 12:09:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263614 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F379EC7EE29 for ; Thu, 1 Jun 2023 12:10:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233351AbjFAMKq (ORCPT ); Thu, 1 Jun 2023 08:10:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233283AbjFAMKg (ORCPT ); Thu, 1 Jun 2023 08:10:36 -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 8F1DD185; Thu, 1 Jun 2023 05:10:30 -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 E16D8641A9; Thu, 1 Jun 2023 12:10:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96BC9C433EF; Thu, 1 Jun 2023 12:10:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621429; bh=TumhD82QuLF3iemxAixVbZIrBkyosIOpPKFtYaO9xHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hGgyvVuZ5OVhoGMX5ceciMv+KWLO8ZPAesvX1NWRUurLKmwfbYvxzOqdr54Vue2/6 EOVfYclvxj7ruH6+I9anSh7koqj0GmxAq+VSrJLipKoykEL2pJSeOQqNdGZaE5eed4 RnhpQY9NeXw2fskX+uNs0feNwN51vqkrP84jkz9DaminwiWeNNP1hbq/fON/6JiW/W 9mOPaHzGkMdioEcOZUH4pH14c7a6HJzJizPXBAtfuvNbaTrXjMRUpnzl7K0tf1W3PT Y6kZ9OqTIBHmqYwhuSiSkKpt7RqU539SLl29uSg8l3wUJubpTIWu2W9634H5YzReiz f4Z4hPIw0Sw8w== 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 Subject: [PATCH 4/7] modpost: refactor find_fromsym() and find_tosym() Date: Thu, 1 Jun 2023 21:09:58 +0900 Message-Id: <20230601121001.1071533-5-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org find_fromsym() and find_tosym() are similar - both of them iterate in the .symtab section and return the nearest symbol. The difference between them is that find_tosym() allows a negative distance, but the distance must be less than 20. Factor out the common part into find_nearest_sym(). Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 95 ++++++++++++++++--------------------------- 1 file changed, 36 insertions(+), 59 deletions(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 5a5e802b160c..32d56efe3f3b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1075,81 +1075,58 @@ static inline int is_valid_name(struct elf_info *elf, Elf_Sym *sym) return !is_mapping_symbol(name); } -/** - * Find symbol based on relocation record info. - * In some cases the symbol supplied is a valid symbol so - * return refsym. If is_valid_name() == true, we assume this is a valid symbol. - * In other cases the symbol needs to be looked up in the symbol table - * based on section and address. - * **/ -static Elf_Sym *find_tosym(struct elf_info *elf, Elf64_Sword addr, - Elf_Sym *relsym) +/* Look up the nearest symbol based on the section and the address */ +static Elf_Sym *find_nearest_sym(struct elf_info *elf, Elf_Addr addr, + unsigned int secndx, bool allow_negative, + Elf_Addr min_distance) { Elf_Sym *sym; Elf_Sym *near = NULL; - Elf64_Sword distance = 20; - Elf64_Sword d; - unsigned int relsym_secindex; - - if (is_valid_name(elf, relsym)) - 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) - continue; - if (ELF_ST_TYPE(sym->st_info) == STT_SECTION) - continue; - if (!is_valid_name(elf, sym)) - continue; - if (sym->st_value == addr) - return sym; - /* Find a symbol nearby - addr are maybe negative */ - d = sym->st_value - addr; - if (d < 0) - d = addr - sym->st_value; - if (d < distance) { - distance = d; - near = sym; - } - } - /* We need a close match */ - if (distance < 20) - return near; - else - return NULL; -} - -/* - * Find symbols before or equal addr and after addr - in the section sec. - * If we find two symbols with equal offset prefer one with a valid name. - * The ELF format may have a better way to detect what type of symbol - * it is, but this works for now. - **/ -static Elf_Sym *find_fromsym(struct elf_info *elf, Elf_Addr addr, - unsigned int secndx) -{ - Elf_Sym *sym; - Elf_Sym *near = NULL; - Elf_Addr distance = ~0; + Elf_Addr distance; for (sym = elf->symtab_start; sym < elf->symtab_stop; sym++) { if (get_secindex(elf, sym) != secndx) continue; if (!is_valid_name(elf, sym)) continue; - if (sym->st_value <= addr && addr - sym->st_value <= distance) { + + if (addr >= sym->st_value) distance = addr - sym->st_value; + else if (allow_negative) + distance = sym->st_value - addr; + else + continue; + + if (distance <= min_distance) { + min_distance = distance; near = sym; } + + if (min_distance == 0) + break; } return near; } +static Elf_Sym *find_fromsym(struct elf_info *elf, Elf_Addr addr, + unsigned int secndx) +{ + return find_nearest_sym(elf, addr, secndx, false, ~0); +} + +static Elf_Sym *find_tosym(struct elf_info *elf, Elf_Addr addr, Elf_Sym *sym) +{ + /* If the supplied symbol has a valid name, return it */ + if (is_valid_name(elf, sym)) + return sym; + + /* + * Strive to find a better symbol name, but the resulting name may not + * match the symbol referenced in the original code. + */ + return find_nearest_sym(elf, addr, get_secindex(elf, sym), true, 20); +} + static bool is_executable_section(struct elf_info *elf, unsigned int secndx) { if (secndx > elf->num_sections) From patchwork Thu Jun 1 12:09:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263615 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F443C77B7E for ; Thu, 1 Jun 2023 12:10:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233387AbjFAMKs (ORCPT ); Thu, 1 Jun 2023 08:10:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233263AbjFAMKp (ORCPT ); Thu, 1 Jun 2023 08:10:45 -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 A64FF197; Thu, 1 Jun 2023 05:10:32 -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 3E8A9643ED; Thu, 1 Jun 2023 12:10:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7128C4339C; Thu, 1 Jun 2023 12:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621431; bh=AZOSF7tPW49wr8oQ2E4HJeege/cPwYFZ1zz3AnaRfDY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ycj27leB07TjGM8InrVlCfTP55GIaTEEQCCqpplZ9wFi+5TpOkJp11ZdLVyxCRsQo 2AzTbHoMHU4YukYqoQInAYk23Ii5jE613W5EsfzrrrnqqUxUSF1hUb61LiSoxi0SSg 0Di4jQW/p33oiQzdwJHd04iNqZ6pr4EWi+MGYE9WHrATJMzvP964qXqyL0Iw/8Xzux +KnzIgwRghfnQGKOVpXY29177mcq3tJ8ptW6p3lqDhMdJisEcRWl2sRw5bZJrFECi8 XqJHSYq1j9TuryuWKAzQYU4CWy5Z+mqQR4LP/zjkfCCWY551eBjG9lMC2Batq6cthK etcxud9XI2WAg== 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 Subject: [PATCH 5/7] modpost: detect section mismatch for R_ARM_THM_{MOVW_ABS_NC,MOVT_ABS} Date: Thu, 1 Jun 2023 21:09:59 +0900 Message-Id: <20230601121001.1071533-6-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org When CONFIG_THUMB2_KERNEL is enabled, modpost fails to detect some types of section mismatches. [test code] #include int __initdata foo; int get_foo(void) { return foo; } It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.text' at offset 0x1e8 contains 2 entries: Offset Info Type Sym.Value Sym. Name 00000000 0000052f R_ARM_THM_MOVW_AB 00000000 .LANCHOR0 00000004 00000530 R_ARM_THM_MOVT_AB 00000000 .LANCHOR0 Currently, R_ARM_THM_MOVW_ABS_NC and R_ARM_THM_MOVT_ABS are just skipped. Add code to handle them. I checked arch/arm/kernel/module.c to learn how the offset is encoded in the instruction. One more thing to note for Thumb instructions - the st_value is an odd value, so you need to mask the bit 0 to get the offset. Otherwise, you will get an off-by-one error in the nearest symbol look-up. It is documented in "ELF for the ARM Architecture" [1]: * If the symbol addresses a Thumb instruction, its value is the address of the instruction with bit zero set (in a relocatable object, the section offset with bit zero set). * For the purposes of relocation the value used shall be the address of the instruction (st_value & ~1). [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 32d56efe3f3b..528aa9175e84 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1082,7 +1082,8 @@ static Elf_Sym *find_nearest_sym(struct elf_info *elf, Elf_Addr addr, { Elf_Sym *sym; Elf_Sym *near = NULL; - Elf_Addr distance; + Elf_Addr sym_addr, distance; + bool is_arm = (elf->hdr->e_machine == EM_ARM); for (sym = elf->symtab_start; sym < elf->symtab_stop; sym++) { if (get_secindex(elf, sym) != secndx) @@ -1090,10 +1091,19 @@ static Elf_Sym *find_nearest_sym(struct elf_info *elf, Elf_Addr addr, if (!is_valid_name(elf, sym)) continue; - if (addr >= sym->st_value) - distance = addr - sym->st_value; + sym_addr = sym->st_value; + + /* + * For ARM Thumb instruction, the bit 0 of st_value is set. + * Mask it to get the address. + */ + if (is_arm) + sym_addr &= ~1; + + if (addr >= sym_addr) + distance = addr - sym_addr; else if (allow_negative) - distance = sym->st_value - addr; + distance = sym_addr - addr; else continue; @@ -1266,7 +1276,7 @@ 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; + uint32_t inst, upper, lower; int32_t offset; switch (r_typ) { @@ -1288,6 +1298,17 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) offset = sign_extend32((inst & 0x00ffffff) << 2, 25); r->r_addend = offset + sym->st_value + 8; break; + case R_ARM_THM_MOVW_ABS_NC: + case R_ARM_THM_MOVT_ABS: + upper = TO_NATIVE(*(uint16_t *)loc); + lower = TO_NATIVE(*((uint16_t *)loc + 1)); + offset = sign_extend32(((upper & 0x000f) << 12) | + ((upper & 0x0400) << 1) | + ((lower & 0x7000) >> 4) | + (lower & 0x00ff), + 15); + r->r_addend = offset + sym->st_value; + break; case R_ARM_THM_CALL: case R_ARM_THM_JUMP24: case R_ARM_THM_JUMP19: From patchwork Thu Jun 1 12:10:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263616 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33EA2C77B7A for ; Thu, 1 Jun 2023 12:10:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232937AbjFAMKy (ORCPT ); Thu, 1 Jun 2023 08:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233364AbjFAMKr (ORCPT ); Thu, 1 Jun 2023 08:10:47 -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 9DE301B8; Thu, 1 Jun 2023 05:10:35 -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 125AF643FB; Thu, 1 Jun 2023 12:10:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DCA2C433A4; Thu, 1 Jun 2023 12:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621434; bh=eRGe47kX3cGM5w4r8Dems50P7VdGPg3OOcR4aC02b70=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q8NKzkee9vISUaZPJodekn7NPcjTrI7T4bZTLzyDUPhJPCb/VPXyphc66ouv2Ccqv x9KwiLJsSMx0NJa1lQynQ7F5ckRdFc45kCK/rzI/I+uPAsZd5gLLgQ5LS61xSOJX5i 2KMSa3pPcU8TjwFyxQul8yT4Bw/bFQHpSTxPXCCpo86tFbTi4d0blMBWVRAfimemUY nXNHvmbcUuktNWNcjr1nvh1Ny9lYyI+eC03OxqMdkMJeJQfP9JMtWNs4bOY19xXJ/t L8IiodTAQOPzflB4mGhCKNEKBhdvpgN4Cywsl0flQMC6sYvGrCtnKJmIWEVoOw2noA RVFF8L9HCvfVw== 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 , "David A. Long" , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , Russell King , Rusty Russell Subject: [PATCH 6/7] modpost: fix section_mismatch message for R_ARM_THM_{CALL,JUMP24,JUMP19} Date: Thu, 1 Jun 2023 21:10:00 +0900 Message-Id: <20230601121001.1071533-7-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org addend_arm_rel() processes R_ARM_THM_CALL, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19 in a wrong way. Here, test code. [test code for R_ARM_THM_JUMP24]   .section .init.text,"ax"   bar:           bx      lr   .section .text,"ax"   .globl foo   foo:           b       bar [test code for R_ARM_THM_CALL]   .section .init.text,"ax"   bar:           bx      lr   .section .text,"ax"   .globl foo   foo:           push    {lr}           bl      bar           pop     {pc} If you compile it with CONFIG_THUMB2_KERNEL=y, modpost will show the symbol name, (unknown).   WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I checked arch/arm/kernel/module.c to learn the encoding of R_ARM_THM_CALL and R_ARM_THM_JUMP24. The module does not support R_ARM_THM_JUMP19, but I checked its encoding in ARM ARM. The '+4' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1].   "If the relocation is pc-relative then compensation for the PC bias   (the PC value is 8 bytes ahead of the executing instruction in Arm   state and 4 bytes in Thumb state) must be encoded in the relocation   by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: c9698e5cd6ad ("ARM: 7964/1: Detect section mismatches in thumb relocations") Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 53 ++++++++++++++++++++++++++++++++++++++----- 1 file changed, 47 insertions(+), 6 deletions(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 528aa9175e84..55d142bb000b 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1276,7 +1276,7 @@ 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, upper, lower; + uint32_t inst, upper, lower, sign, j1, j2; int32_t offset; switch (r_typ) { @@ -1309,13 +1309,54 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) 15); r->r_addend = offset + sym->st_value; break; + case R_ARM_THM_JUMP19: + /* + * Encoding T3: + * S = upper[10] + * imm6 = upper[5:0] + * J1 = lower[13] + * J2 = lower[11] + * imm11 = lower[10:0] + * imm32 = SignExtend(S:J2:J1:imm6:imm11:'0') + */ + upper = TO_NATIVE(*(uint16_t *)loc); + lower = TO_NATIVE(*((uint16_t *)loc + 1)); + + sign = (upper >> 10) & 1; + j1 = (lower >> 13) & 1; + j2 = (lower >> 11) & 1; + offset = sign_extend32((sign << 20) | (j2 << 19) | (j1 << 18) | + ((upper & 0x03f) << 12) | + ((lower & 0x07ff) << 1), + 20); + r->r_addend = offset + sym->st_value + 4; + break; case R_ARM_THM_CALL: case R_ARM_THM_JUMP24: - case R_ARM_THM_JUMP19: - /* From ARM ABI: ((S + A) | T) - P */ - r->r_addend = (int)(long)(elf->hdr + - sechdr->sh_offset + - (r->r_offset - sechdr->sh_addr)); + /* + * Encoding T4: + * S = upper[10] + * imm10 = upper[9:0] + * J1 = lower[13] + * J2 = lower[11] + * imm11 = lower[10:0] + * I1 = NOT(J1 XOR S) + * I2 = NOT(J2 XOR S) + * imm32 = SignExtend(S:I1:I2:imm10:imm11:'0') + */ + upper = TO_NATIVE(*(uint16_t *)loc); + lower = TO_NATIVE(*((uint16_t *)loc + 1)); + + sign = (upper >> 10) & 1; + j1 = (lower >> 13) & 1; + j2 = (lower >> 11) & 1; + offset = sign_extend32((sign << 24) | + ((~(j1 ^ sign) & 1) << 23) | + ((~(j2 ^ sign) & 1) << 22) | + ((upper & 0x03ff) << 12) | + ((lower & 0x07ff) << 1), + 24); + r->r_addend = offset + sym->st_value + 4; break; default: return 1; From patchwork Thu Jun 1 12:10:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Masahiro Yamada X-Patchwork-Id: 13263617 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DBD0C7EE2A for ; Thu, 1 Jun 2023 12:11:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229589AbjFAMLa (ORCPT ); Thu, 1 Jun 2023 08:11:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233293AbjFAMKt (ORCPT ); Thu, 1 Jun 2023 08:10:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A8DEE50; Thu, 1 Jun 2023 05:10:37 -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 282C2641A9; Thu, 1 Jun 2023 12:10:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1781C433A0; Thu, 1 Jun 2023 12:10:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685621436; bh=eMacqv00K8bJeMNK92sV1H4jFGoCI1e91wlVYvSCA6I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SbJwf4gmpXiXBcoZnqcOtwMctCfgu2govvYcmytWmux8JMSq+1RHR2N8rpx5KZ6UF 61/5EPxVCs0pxoO+Cl7pnYYQdM5MLEND+6FtFQW07RgnQDL0wPPTjpytv2U9+o3u8w K4m/fy0y5W+ZffGmTazVcbnRCHk9hfC5uNOrOXXL/rGv+WrlFRPr8bYFK2Egu7vrnv rNqA92cuyyZ30DO+n2qxlQyMyzhdXr0tjpdf4DSQRxxMiU0SZnqzhYibEkuE+Lg+I1 rTiYQDHSJiFa+EobEK9N1ZeM2SvTguMeOX45UOjKaIc11CEEFiA9L7TA7Bp8rBJed+ Inyd6OuukOmzw== 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 Subject: [PATCH 7/7] modpost: detect section mismatch for R_ARM_REL32 Date: Thu, 1 Jun 2023 21:10:01 +0900 Message-Id: <20230601121001.1071533-8-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 Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org For ARM, modpost fails to detect some types of section mismatches. [test code] .section .init.data,"aw" bar: .long 0 .section .data,"aw" .globl foo foo: .long bar - . It is apparently a bad reference, but modpost does not report anything. The test code above produces the following relocations. Relocation section '.rel.data' at offset 0xe8 contains 1 entry: Offset Info Type Sym.Value Sym. Name 00000000 00000403 R_ARM_REL32 00000000 .init.data Currently, R_ARM_REL32 is just skipped. Handle it like R_ARM_ABS32. Signed-off-by: Masahiro Yamada --- scripts/mod/modpost.c | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 55d142bb000b..9f0c87064ca5 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1281,6 +1281,7 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) switch (r_typ) { case R_ARM_ABS32: + case R_ARM_REL32: inst = TO_NATIVE(*(uint32_t *)loc); r->r_addend = inst + sym->st_value; break;