🚀 go-pugleaf

Hi,

I am facing exactly the same problem as mentioned above. I am using kgdb on
x86_64 machine with Debian installation. 
Even I don't see CONFIG_DEBUG_LL option in the .config file.

Did you get any resolution to this problem? Please let me know. Any pointers
in this direction will be of great help. The only thing I feel troubling is
that I am having separate builds in the test and the development machines
(and I am not copying the vmliniz.xx and initrd from one machine to the
other) .

Thanks,
Sambit Das
UC San Diego

Alexandre Rusev wrote:
> 
> 清水河 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
> 
> 

-- 
View this message in context: http://old.nabble.com/gdb-show----symbols-tp26903197p28647099.html
Sent from the Gnu - gdb - Bugs mailing list archive at Nabble.com.