Gdb: Lx-Symbols Undefined Command

GDB: lx-symbols undefined command

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

How to debug Linux kernel modules with QEMU?

The easiest way in my opinion is to use buildroot
http://buildroot.uclibc.org/

clone it, configure it to use your custom kernel (default userspace is fine for a start, you might want to change it later).

it will build your kernel and root filesystem. the entire process takes about half an hour, twenty minutes of which is compiling the monster

my run line looks something:
qemu-system-i386
-hda rootfs.ext2
-kernel bzImage
-m 512M
-append "root=/dev/sda console=ttyS0"
-localtime
-serial stdio

and some more options regarding a tap device

kernel module no debugging symbols found

My flags were incorrect. Debugging symbol table is built with this makefile:

obj-m += mmaptest.o
MY_CFLAGS += -g -DDEBUG
ccflags-y += ${MY_CFLAGS}
CC += ${MY_CFLAGS}

all:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

debug:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules 
        EXTRA_CFLAGS="$(MY_CFLAGS)"
clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean 

This can be verified now with:

peter@c4:$ readelf -S mmaptest.ko | grep debug

  [24] .debug_info       PROGBITS         0000000000000000  00000d40
  [25] .rela.debug_info  RELA             0000000000000000  00018260
  [26] .debug_abbrev     PROGBITS         0000000000000000  0000d577
  [27] .debug_loc        PROGBITS         0000000000000000  0000dd54
  [28] .rela.debug_loc   RELA             0000000000000000  00029510
  [29] .debug_aranges    PROGBITS         0000000000000000  0000e5d5
  [30] .rela.debug_arang RELA             0000000000000000  0002a3e0
  [31] .debug_ranges     PROGBITS         0000000000000000  0000e645
  [32] .rela.debug_range RELA             0000000000000000  0002a458
  [33] .debug_line       PROGBITS         0000000000000000  0000e815
  [34] .rela.debug_line  RELA             0000000000000000  0002a878
  [35] .debug_str        PROGBITS         0000000000000000  0000f4cd
  [38] .debug_frame      PROGBITS         0000000000000000  00016e80
  [39] .rela.debug_frame RELA             0000000000000000  0002a8c0

add symbol table from file "/home/peter/projects/svn/linux_kernel/mmaptest/mmaptest.ko"
at .text_addr = 0x0
(y or n) y
Reading symbols from /home/peter/projects/svn/linux_kernel/mmaptest/mmaptest.ko...done.
(gdb) 

GDB automate commands after symbols have been loaded

You are probably using .gdbinit for purposes including some which would be better accomplished with a command file passed by the -x [cmds_file] command line option.

A little experimentation shows that the .gdbinit is run before the program file is loaded, while the -x file is run after.

Can't get Qt to find the debugging helper

This site claims you need to configure GDB using

./configure --with-python

Undefined info command: goroutines

The article "Debugging Go Code with GDB" does mention:

(gdb) info goroutines

But only in the context of loading extension scripts for a given binary.

The tool chain uses this to extend GDB with a handful of commands to inspect internals of the runtime code (such as goroutines) and to pretty print the built-in map, slice and channel types.

If you'd like to see how this works, or want to extend it, take a look at src/pkg/runtime/runtime-gdb.py in the Go source distribution.

It depends on some special magic types (hash<T,U>) and variables (runtime.m and runtime.g) that the linker (src/cmd/ld/dwarf.c) ensures are described in the DWARF code.

If you're interested in what the debugging information looks like, run 'objdump -W 6.out' and browse through the .debug_* sections.

So make sure your debug session is run with those extensions activated.

---

Related Topics