On Thu, 9 May 2024 14:44:22 +0200 alexandre.ferrieux@xxxxxxxxxx wrote: > Hi, > > Ftrace is a jewel to dig into the kernel, be it for troubleshooting, perf tuning > or just understanding. > But when one needs to disassemble the running kernel (eg to move kprobes around > in a function, in order to understand a given code path), KASLR makes it > impossible for gdb to get useful symbol addresses, even with a debug image. Really? Can't you just use a function name plus offset? For instance, I do this all the time: (gdb) li vfs_write+0xc3 0xffffffff812e2513 is in vfs_write (/work/git/linux-trace.git/fs/read_write.c:592). 587 return ret; 588 if (count > MAX_RW_COUNT) 589 count = MAX_RW_COUNT; 590 file_start_write(file); 591 if (file->f_op->write) 592 ret = file->f_op->write(file, buf, count, pos); 593 else if (file->f_op->write_iter) 594 ret = new_sync_write(file, buf, count, pos); 595 else 596 ret = -EINVAL; (gdb) disass 0xffffffff812e2513 [..] 0xffffffff812e250e <+190>: call 0xffffffff82202bc0 <__x86_indirect_thunk_array> 0xffffffff812e2513 <+195>: mov %rax,%r12 0xffffffff812e2516 <+198>: test %r12,%r12 0xffffffff812e2519 <+201>: jg 0xffffffff812e257c <vfs_write+300> And I can add a kprobe the same way: # cd /sys/kernel/tracing # echo 'p:write vfs_write+0xc3 a=%ax' > kprobe_events # trace-cmd start -e write # trace-cmd show [..] trace-cmd-884 [006] d.Z.. 563.447396: write: (vfs_write+0xc3/0x2b0) a=0x1 NetworkManager-461 [000] d.Z.. 564.791375: write: (vfs_write+0xc3/0x2b0) a=0x8 NetworkManager-461 [000] d.Z.. 564.791408: write: (vfs_write+0xc3/0x2b0) a=0x8 > That said, /proc/kallsyms always gives the accurate, present symbol addresses. > But, to my knowledge, gdb isn't able to import /proc/kallsyms as a symbol table. > To circumvent this, I've written a small userland tool, usling libbfd, that > creates an ELF file out of /proc/kallsyms. Passing this ELF file to gdb instead > of "vmlinux", and /proc/kcore as core, then allows for a perfect gdb session on > the running kernel. Of course this ELF file is only valid until the next reboot, > but that's okay as its creation is fast. > > Now, my question: did I miss an alternative ? > > In other words, is there some kind of "kallsyms plug-in" for gdb somewhere ? > Or, taking the problem from the other side, some kernel module exposing a > "/proc/kallsyms.elf" or similar, for direct consumption by gdb ? > Or another method, that people routinely use for the same purpose ? > Do you need the absolute address? Can't you just use the offset of functions? -- Steve