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
|