[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXFJOHsgopUOR7+jvC8s6bvSCZ3XAkQM1FbnZ8Qj6azvQA@mail.gmail.com>
Date: Thu, 1 Jun 2023 14:40:44 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Russell King <linux@...linux.org.uk>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>
Subject: Re: [PATCH 7/7] modpost: detect section mismatch for R_ARM_REL32
On Thu, 1 Jun 2023 at 14:10, Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> 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.
OK, so the reason we can handle these in the same way is because we
never calculate the resulting value, right? Because that value would
be different for these cases.
>
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
>
> 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;
> --
> 2.39.2
>
Powered by blists - more mailing lists