清水河 wrote: > On Dec 24, 2:00 am, Alexandre Rusev <aru...@ru.mvista.com> wrote: > >> 你好!;) >> >> 清水河 wrote: >> >>> Hi, I tried to use gdb to debug kernel code. >>> I compiled with -g -ggdb flags, but it seems gdb cannot show symbols >>> correctly, instead it shows all ?? >>> >> compile kernel with debug information. >> In kernel compilation menu "make menuconfig" select Kernel >> Hucking->Compile kernel with Debug information, >> there are anumber of kernel debugging related options to turn on. >> >> Which processor architecture you compiling your kernel for? >> > > Hi, it is i386. Seems there is no "Compile kernel with Debug > the mainstream i386 architecture usually works fine ... strange > information" option, under "kernel debugging", there are several debug > options, like "Debug shared IRQ handlers", "Detect Soft Lockups", etc, > but which one is the option that have the source information? > > Typical settings in .config file (and make menuconfig) would be:
CONFIG_DEBUG_KERNEL Kernel debugging CONFIG_DEBUG_LL Compile the kernel with debug info CONFIG_DEBUG_BUGVERBOSE Verbose BUG() reporting Make sure that you are debugging an executable "vmlinux" in your GDB session. Got to the directory you compiled your kernel and start debugging of vmlinux likes this: cd linux-2.6.xx gdb vmlinux gdb target remote /dev/pts/11 ... your GDB tool have to have the ELF image of the kernel being debugged and the sources should present starting from the current path. I guess that there also may be some issues with GDB itself when you debugging the kernel modules, but if you compile the solid kernel (modules compiled in kernel image) the code of these modules must be step debugged quite well At the machine you are debugging the kernel run "cat /proc/kallsyms" and see if the information about symbol names is really available Here is beginning of an example of output at x86 target: cat /proc/kallsyms c01002c0 T _stext c01002c0 t run_init_process c01002c0 T stext c01002fc t init c01005b8 t rest_init c01005d8 t try_name c010079f T name_to_dev_t c0100a0c T calibrate_delay c0100c70 T hard_smp_processor_id c0100c80 t target_cpus c0100c87 t check_apicid_used c0100c8a t check_apicid_present c0100c90 t multi_timer_check c0100c93 t apic_id_registered c0100c99 t apicid_to_node c0100c9d t cpu_to_logical_apicid c0100cb1 t cpu_present_to_apicid ... >>> Remote debugging using /dev/pts/11 >>> 0xc0467118 in ?? () >>> (gdb) where >>> #0 0xc0467118 in ?? () >>> #1 0xc077db2d in ?? () >>> #2 0x00000000 in ?? () >>> >>> how to solve this problem? >>> _______________________________________________ >>> bug-gdb mailing list >>> bug-...@gnu.org >>> http://lists.gnu.org/mailman/listinfo/bug-gdb >>> > > _______________________________________________ > bug-gdb mailing list > bug-gdb@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-gdb >
_______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
