0

I am trying to use gdb to read memory from vmlinux. The exact syntax is

sudo gdb vmlinux-4.18.0-rc1+ /proc/kcore

I use this file because vmlinux is a symlink to this file. The result is the following

Reading symbols from vmlinux-4.18.0-rc1+...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New process 1]
Core was generated by `root=/dev/mapper/rcs--power9--talos--vg-root ro console=hvc0 quiet'.
#0  0x0000000000000000 in ?? ()
(gdb) x/4xb 0xfffffff0
0xfffffff0:     Cannot access memory at address 0xfffffff0
(gdb) print &sys_call_table
No symbol table is loaded.  Use the "file" command.
(gdb)

The file vmlinux-4.18.0-rc1+ is in /boot. The file type is as follows:

root@rcs-power9-talos:/boot# file vmlinux-4.18.0-rc1+ vmlinux-4.18.0-rc1+: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, BuildID[sha1]=a1c9f3fe22ff5cbf419787657c878c8a07e559b2, stripped

I modified the config-4.18.0-rc1+ file such that every CONFIG_DEBUG option is set to yes. I then rebooted the system. My questions are:

  1. Do I need to do anything else for the changes I made to /boot/config-4.18.0-rc1+ to take effect?
  2. Based on the file type of vmlinux-4.18.0-rc1+, does it seem that this file should work for debugging?

I did not build the kernel myself. It is a custom build from Raptor Computer Systems.

Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
Jerry9013
  • 1
  • 2

1 Answers1

0

The config-* file you've modified is just for reference - all these options have already been compiled into the kernel, so changing them will not have any effect.

However, you can get any symbol you want in two steps:

  • consult /proc/kallsyms (e.g. grep sys_call_table /proc/kallsyms). Get the address. Note, that this might appear as 0x00000000 - which can be fixed by setting /proc/sys/kernel/kptr_restrict to 0

  • Then use above address as direct argument. You will still run into minor issues (e.g. "print" won't know what datatype it is, but x/20x for example will work) , but these can be resolved with a bit of gdb scripting, or providing an external dwarf file.

Technologeeks
  • 7,674
  • 25
  • 36
  • Thank you! I'm still having a few issues. First, sys_call_table does not appear in /proc/kallsyms. /proc/sys/kernel/kptr_restrict was already set to 0. Second, when I try to print memory using something like x/20x, I get the following: (gdb) x/20x 0xbbbb 0xbbbb: Cannot access memory at address 0xbbbb This is the case for any address I try from /proc/kallsyms. What may account for these issues? – Jerry9013 Sep 09 '20 at 18:06
  • so , sys_call_table might not be exported, or be named differently on PPC (I've handled many an architecture Linux was on, but never that). As for the addresses not being read, I'd suggest trying a few and seeing where that gets you. Some addresses may either not be mapped, or be cache addresses (usually marked 'A') and thus not accessible in core. Try ones starting with other prefixes. – Technologeeks Sep 10 '20 at 12:13
  • If the sys_call_table isn't exported, would I need to rebuild the kernel in order for this to work? Also I've tried printing out a ton of random addresses and none of them seem to work. – Jerry9013 Sep 10 '20 at 15:20
  • you can figure out the sys_call_table dynamically from the binary. And maybe I should have been more clear : "random" addresses = addresses from /proc/kallsyms, not just any – Technologeeks Sep 10 '20 at 16:17
  • As it turns out, I can use /proc/kcore to view virtual memory instead. I've been using dd to copy data from it, ex. dd if=/proc/kcore of=filedump.txt bs=1024 skip=1024 count=1024. – Jerry9013 Sep 19 '20 at 04:04