On 3/11/26 11:34, Vivian Wang wrote: > Hi Sasha, > > I've been trying this out and AFAICT this does work perfectly. Thank you > for this. > > There are a few oddities I found: > > Firstly I've been building with something like O=_riscv out of > convenience, and the file names have an extra ../ in the front. (This is > just me exiting out of init=/bin/sh.) > > [ 2.317268] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x00000000 > [ 2.320283] CPU: 0 UID: 0 PID: 1 Comm: sh Not tainted > 7.0.0-rc3-00004-g8ad18f1a1a2f #31 PREEMPTLAZY > [ 2.322048] Hardware name: riscv-virtio,qemu (DT) > [ 2.323220] Call Trace: > [ 2.324465] [<ffffffff800172a8>] dump_backtrace+0x1c/0x24 > (../arch/riscv/kernel/stacktrace.c:150) > [ 2.329061] [<ffffffff8000241e>] show_stack+0x2a/0x34 > (../arch/riscv/kernel/stacktrace.c:156) > [ 2.330334] [<ffffffff8000fe32>] dump_stack_lvl+0x4a/0x68 > (../lib/dump_stack.c:122) > [ 2.331462] [<ffffffff8000fe64>] dump_stack+0x14/0x1c > (../lib/dump_stack.c:130) > [ 2.332571] [<ffffffff80002a88>] vpanic+0x108/0x2bc (../kernel/panic.c:651) > [ 2.333674] [<ffffffff80002c6e>] panic+0x32/0x34 (../kernel/panic.c:787) > [ 2.334427] [<ffffffff8002e97a>] do_exit+0x7ee/0x7f4 (../kernel/exit.c:930) > [ 2.335194] [<ffffffff8002eade>] do_group_exit+0x1a/0x88 > (../kernel/exit.c:1099) > [ 2.335945] [<ffffffff8002eb62>] __riscv_sys_exit_group+0x16/0x18 > (../kernel/exit.c:1129) > [ 2.336763] [<ffffffff80b3e868>] do_trap_ecall_u+0x260/0x45c > (../arch/riscv/include/asm/syscall.h:112) > [ 2.337765] [<ffffffff80b4c034>] handle_exception+0x168/0x174 > (../arch/riscv/kernel/entry.S:233) > > This is fine by me, but I've seen mentions of O= builds but I'm not sure > if it's expected. > > Also, toggling CONFIG_KALLSYMS_LINEINFO seems to rebuild every single > file. I haven't debugged why, but is this expected? > > I have a few ideas about the code as well. Since this patch 3 touches > most of the files involved, I'll just dump my thoughts on the whole > series here. I want to note that I haven't read the RFC thread too > carefully, but I don't think there were many comments on the implementation.
Uh, oops, I just realized I was replying on v1 not v2. Most of my idea should still apply. One notable idea was the module lineinfo header offset/size one. I see that one of the things addressed in v2 was the alignment after compressed data. If we'd been using offset/size in the header it would be just, code-wise, one extra .balign 4 and done. No need to fiddle with alignment when decoding in mod_lineinfo_file_offsets_off(). Sorry for the inconvenience.
