On 6/1/26 9:57 PM, Steven Rostedt wrote:
On Mon, 1 Jun 2026 14:17:08 +0800 Shuai Xue <[email protected]> wrote:diff --git a/scripts/sorttable.c b/scripts/sorttable.c index e8ed11c680c6..4c10e85bb5af 100644 --- a/scripts/sorttable.c +++ b/scripts/sorttable.c @@ -891,17 +891,21 @@ static int do_file(char const *const fname, void *addr) table_sort_t custom_sort = NULL;switch (elf_map_machine(ehdr)) {- case EM_AARCH64: #ifdef MCOUNT_SORT_ENABLED + case EM_AARCH64: sort_reloc = true; rela_type = 0x403; - /* arm64 uses patchable function entry placing before function */ + /* fallthrough */ + case EM_RISCV: + /* arm64 and RISC-V place patchable entries before the function */ before_func = 8;Nit: The shared comment now sits under `case EM_RISCV:` but the two lines above it (sort_reloc / rela_type = 0x403) are strictly arm64-only — they configure the RELA-based weak-function fixup that RISC-V does not need. On a quick read it is easy to wonder if RISC-V is implicitly inheriting that path. Splitting the comments would help, e.g.: case EM_AARCH64: /* arm64 needs RELA-based weak-function fixup */ sort_reloc = true; rela_type = 0x403; /* fallthrough */ case EM_RISCV: /* arm64 and RISC-V place patchable entries before the function */ before_func = 8;Makes sense. Care to send a v3? -- Steve
Hi, Steve, It's a pure comment cosmetic, not worth a respin on its own. But for the rest of the feedback on this series (the frame-record metadata contract in patch 2 and the dead state->regs field / Call Trace output change in patch 6) are the ones actually worth a new version. Just to get the routing straight: are you planning to pick this one up through the tracing tree on its own? It feels like a good candidate for that -- it's an independent regression fix (Fixes: 0ca1724b56af) that breaks *all* RISC-V dynamic ftrace, not just livepatch, so it shouldn't have to wait on the rest of the livepatch series. Thanks. Shuai
