GDB: lx-symbols undefined command

Question

I am following the guide below: Debugging kernel and modules via gdb

When I try to load the module symbols using the command below: (gdb) lx-symbols

gdb says that the command is undefined. How do I add these helper command to gdb?

gdb info: gdb-7.6.1-51.el7.x86-64 on Centos 7.0

Mccutcheon

what does (gdb) apropos lx show – Skiascope

Answer 1

You have to get the latest kernel sources (may be 4.0-rc4) or backport the patch. Basically see if you have script/gdb/ directory like this in your kernel sources. Because that is where you get these scripts.

Then you follow the steps mentioned in Debugging kernel and modules via gdb

Skiascope

I used 'git' to get the kernel source from git://git.kiszka.org/linux.git. The script/gdb directory was there. Verified that CONFIG_GDB_SCRIPTS and CONFIG_KGDB and other DBG flags were set in .config . Compiled and installed the new kernel. I read the Makefile and there was a reference to a vmlinux-gdb.py script. However, I cannot find this script anywhere in the new kernel. It stays in the build source tree. How do I check if my build is correctly done? – Mccutcheon

Isnt it in the build source tree in scripts/gdb/ – Skiascope

Yes, vmlinux-gdb.py is in the build source tree. Can I manually copy it to the new kernel tree? – Mccutcheon

What new kernel. You mentioned that you found the scripts/ directory. I already mentioned that if you can not see this code in the patch, you have to backport it. Yes you can try copying the scripts/gdb/ directory. Did you just downvote my answer? – Skiascope

No, I didn't downvote (i dont have enough points to vote either way). – Mccutcheon

The kernel source is directly from the author of the patch web site. So script/gdb is there. Next I compiled and installed this kernel ("new kernel") on the target computer (a VM running a host computer). Do I also need to install the patched kernel on the host computer? – Mccutcheon

I do not understand why you need the scripts on target machine? Aren't these scritps supposed to do something with the build directory. See these two steps where you cd /path/to/linux-build and then Start gdb: gdb vmlinux. These are supposed to happen where you built the sources. – Skiascope

Here are the steps I did: - Download the kernel source with the patch. - Compile the kernel source. - Load it on the VM computer. - Start the VM computer. - Run "gdb vmlinux" on the host computer. – Mccutcheon

- gdb stops at a break point. - enter lx-symbols and get command not found. and yes the kernel source contains the script/gdb folder (the latest snapshot of it). – Mccutcheon

I used the gdb command info auto-load python-scripts to actually see that the script was not loaded. The script symlink at the top-level directory was broken because I copied the build directory from a vm to my host in a different location and the symlink is actually an absolute path instead of being relative. Fixing the symlink using ln -sf scripts/gdb/vmlinux-gdb.py and reloading gdb fixed the issue for me. – Lunette

Answer 2

add-auto-load-safe-path

Usage:

gdb -ex add-auto-load-safe-path /path/to/linux/kernel/source/root

Now the GDB scripts are automatically loaded, and lx-symbols is available.

Here is a minimal fully automated Buildroot + QEMU example with detailed instructions.

Fiedling

Answer 3

I also faced similar issue. In my case the issue raised because i haven't set the auto-load safe-path to ../scripts/gdb/vmlinux-gdb.py. so i created ~/.gdbinit file added

add-auto-load-safe-path path/to/linux/kernel/tree/scripts/gdb/vmlinux-gdb.py

Shawanda