Message ID | 20230615072302.25638-1-nylon.chen@sifive.com (mailing list archive) |
---|---|
State | Handled Elsewhere |
Headers | show |
Series | [v2] RISC-V: Support 32_PCREL relocation type in kernel module | expand |
Context | Check | Description |
---|---|---|
conchuod/cover_letter | success | Single patches do not need cover letters |
conchuod/tree_selection | success | Guessed tree name to be for-next at HEAD d5e45e810e0e |
conchuod/fixes_present | success | Fixes tag not required for -next series |
conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 6 and now 6 |
conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
conchuod/build_rv64_clang_allmodconfig | success | Errors and warnings before: 8 this patch: 8 |
conchuod/module_param | success | Was 0 now: 0 |
conchuod/build_rv64_gcc_allmodconfig | success | Errors and warnings before: 8 this patch: 8 |
conchuod/build_rv32_defconfig | success | Build OK |
conchuod/dtb_warn_rv64 | success | Errors and warnings before: 3 this patch: 3 |
conchuod/header_inline | success | No static functions without inline keyword in header files |
conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 22 lines checked |
conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
conchuod/verify_fixes | success | No Fixes tag |
conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
On Jun 15 2023, Nylon Chen wrote: > Fix the 'unsupported relocation type' error caused by > enabling the -fasynchronous-unwind-tables flag, > which generates relocation types that are not supported. arch/riscv/Makefile has KBUILD_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables
Hey Nylon, thanks for the update. On Thu, Jun 15, 2023 at 03:23:02PM +0800, Nylon Chen wrote: > Fix the 'unsupported relocation type' error caused by > enabling the -fasynchronous-unwind-tables flag, > which generates relocation types that are not supported. What commit adds the -fasynchronous-unwind-tables flag? Should there be a Fixes: tag for that commit? Cheers, Conor. > > Signed-off-by: Nylon Chen <nylon.chen@sifive.com> > Reviewed-by: Zong Li <zong.li@sifive.com> > --- > Changed in v2: > - add commit message. > > arch/riscv/kernel/module.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c > index 7c651d55fcbd..65be0360a494 100644 > --- a/arch/riscv/kernel/module.c > +++ b/arch/riscv/kernel/module.c > @@ -310,6 +310,15 @@ static int apply_r_riscv_sub64_rela(struct module *me, u32 *location, > return 0; > } > > +static int apply_r_riscv_pcrel_32_rela(struct module *me, u32 *location, > + Elf_Addr v) > +{ > + ptrdiff_t offset = (void *)v - (void *)location; > + > + *location = (*location & 0xffff0000) | (offset & 0xffff); > + return 0; > +} > + > static int (*reloc_handlers_rela[]) (struct module *me, u32 *location, > Elf_Addr v) = { > [R_RISCV_32] = apply_r_riscv_32_rela, > @@ -335,6 +344,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location, > [R_RISCV_SUB16] = apply_r_riscv_sub16_rela, > [R_RISCV_SUB32] = apply_r_riscv_sub32_rela, > [R_RISCV_SUB64] = apply_r_riscv_sub64_rela, > + [R_RISCV_32_PCREL] = apply_r_riscv_pcrel_32_rela, > }; > > int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab, > -- > 2.40.1 >
On Jun 15 2023, Nylon Chen wrote:
> I mean, when we use the flag "-fasynchronous-unwind-tables,"
Why?
Hey Nylon, Firstly, no html emails please :/ On Thu, Jun 15, 2023 at 03:52:27PM +0800, Nylon Chen wrote: > Conor Dooley <conor.dooley@microchip.com<mailto:conor.dooley@microchip.com>> 於 2023年6月15日 週四 下午3:38寫道: > > On Thu, Jun 15, 2023 at 03:23:02PM +0800, Nylon Chen wrote: > > > Fix the 'unsupported relocation type' error caused by > > > enabling the -fasynchronous-unwind-tables flag, > > > which generates relocation types that are not supported. > > > > What commit adds the -fasynchronous-unwind-tables flag? > sorry my description is not correct, please allow me to add > > I mean, when we use the flag "-fasynchronous-unwind-tables," it generates > the relocation type R_RISCV_32_PCCREL. However, this type is currently not > supported, so an error will occur. (snip) > > Should there be a Fixes: tag for that commit? > yes, I will do it. What mainline commit actually enables this flag? Cheers, Conor.
On Thu, Jun 15, 2023 at 09:11:33AM +0100, Conor Dooley wrote: Hi Conor, > Hey Nylon, > > Firstly, no html emails please :/ Sorry, my Gmail settings got messed up. I will be more careful in the future. > > On Thu, Jun 15, 2023 at 03:52:27PM +0800, Nylon Chen wrote: > > Conor Dooley <conor.dooley@microchip.com<mailto:conor.dooley@microchip.com>> 於 2023年6月15日 週四 下午3:38寫道: > > > On Thu, Jun 15, 2023 at 03:23:02PM +0800, Nylon Chen wrote: > > > > Fix the 'unsupported relocation type' error caused by > > > > enabling the -fasynchronous-unwind-tables flag, > > > > which generates relocation types that are not supported. > > > > > > What commit adds the -fasynchronous-unwind-tables flag? > > sorry my description is not correct, please allow me to add > > > > I mean, when we use the flag "-fasynchronous-unwind-tables," it generates > > the relocation type R_RISCV_32_PCCREL. However, this type is currently not > > supported, so an error will occur. > > (snip) > > > > Should there be a Fixes: tag for that commit? > > > yes, I will do it. > > What mainline commit actually enables this flag? Because LLVM currently has it enabled by default(https://reviews.llvm.org/D145164), it will generate this relocation type. From what I know, GCC will also enable it in the future. > > Cheers, > Conor.
On Jun 15 2023, Nylon Chen wrote: > Because LLVM currently has it enabled by default(https://reviews.llvm.org/D145164), it will generate this > relocation type. > >>From what I know, GCC will also enable it in the future. That's why the kernel explicitly disables it.
On Thu, Jun 15, 2023 at 11:11:49AM +0200, Andreas Schwab wrote: > On Jun 15 2023, Nylon Chen wrote: > Hi Andreas, > > Because LLVM currently has it enabled by default(https://reviews.llvm.org/D145164), it will generate this > > relocation type. > > > >>From what I know, GCC will also enable it in the future. > > That's why the kernel explicitly disables it. Ok, thanks for your feedback, after I cross-tested, there is indeed no relevant relocation type generated. If this error no longer occurs. I am open to the idea of adding this patch to the upstream and would like to hear your thoughts on whether it is still necessary. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
Hi Andreas, Currently, due to the lack of support for the unwind table in RISC-V, we have disabled it. If RISC-V were to support the unwind table in the future, would we need to re-enable it? Would this require implementing related changes(module relocation type handler) at that time? Nylon Chen <nylon.chen@sifive.com> 於 2023年6月15日 週四 下午5:47寫道: Nylon Chen <nylon.chen@sifive.com> 於 2023年6月15日 週四 下午5:47寫道: > > On Thu, Jun 15, 2023 at 11:11:49AM +0200, Andreas Schwab wrote: > > On Jun 15 2023, Nylon Chen wrote: > > > Hi Andreas, > > > Because LLVM currently has it enabled by default(https://reviews.llvm.org/D145164), it will generate this > > > relocation type. > > > > > >>From what I know, GCC will also enable it in the future. > > > > That's why the kernel explicitly disables it. > Ok, thanks for your feedback, after I cross-tested, there is indeed no relevant relocation type generated. > > If this error no longer occurs. > > I am open to the idea of adding this patch to the upstream and would like to hear your thoughts on whether it is still necessary. > > > > -- > > Andreas Schwab, SUSE Labs, schwab@suse.de > > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > > "And now for something completely different."
On Aug 21 2023, Nylon Chen wrote: > If RISC-V were to support the unwind table in the future, would we > need to re-enable it? Would this require implementing related > changes(module relocation type handler) at that time? I'm not quite sure I understand your question. Nothing in the kernel makes use of unwind tables on RISC-V, so there is no point in generating them.
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c index 7c651d55fcbd..65be0360a494 100644 --- a/arch/riscv/kernel/module.c +++ b/arch/riscv/kernel/module.c @@ -310,6 +310,15 @@ static int apply_r_riscv_sub64_rela(struct module *me, u32 *location, return 0; } +static int apply_r_riscv_pcrel_32_rela(struct module *me, u32 *location, + Elf_Addr v) +{ + ptrdiff_t offset = (void *)v - (void *)location; + + *location = (*location & 0xffff0000) | (offset & 0xffff); + return 0; +} + static int (*reloc_handlers_rela[]) (struct module *me, u32 *location, Elf_Addr v) = { [R_RISCV_32] = apply_r_riscv_32_rela, @@ -335,6 +344,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 *location, [R_RISCV_SUB16] = apply_r_riscv_sub16_rela, [R_RISCV_SUB32] = apply_r_riscv_sub32_rela, [R_RISCV_SUB64] = apply_r_riscv_sub64_rela, + [R_RISCV_32_PCREL] = apply_r_riscv_pcrel_32_rela, }; int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,