Re: Deciphering Call Trace details

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 4, 2009 at 7:03 PM, yogeshwar sonawane <yogyas@xxxxxxxxx> wrote:
> Hi all,
>
> I was searching on the net for solving oops. This thread/discussion
> helped me alot.
> Thanks to all.
>
> I tried objdump & gdb on vmlinux. Using this, i am able to get
> information about kernel functions & their symbols.
>
> Now, if a module (created by a used) is giving kernel-panic/oops
> messages, then whether objdump/gdb will give info for that module also
> ?

By default if it is your module and you have loaded it, it won't give
you and if you see a backtrace you will be seeing just ??() where your
function was called. To see the symbols you will have to export the
symbol file for your module. Typical steps would be first determining
the load address of your module and then adding symbol file.

In gdb do the following :-

(gdb) p modules
This will give you some address say 0xabcdef84, subtract 4 bytes from it and do

(gdb) p *(struct modules *)0xabcdef80
This will give you the address of your loadpoint, look for some field
name as "module_incore". Say you get 0xfedcba70

Verify from the module name that this is your module, if it is not you
will need to traverse the linked list till you find your module and
then print its contents.

(gdb)add-symbol-file /home/myuser/mymodule.ko 0xfedcba70
After this step you should have the symbols

(gdb) bt

Thanks -
Manish

>The module will be loaded separately(not built-in module).
>
> OR
>
> how to detect/trace a module symbol/function causing panic/oops ?
>
> Any help/links/reference is welcome.
>
> TIA,
> Yogeshwar
>
> On Thu, Jun 12, 2008 at 9:45 PM, Wenhua Zhao <whzhao@xxxxxxxxx> wrote:
>>
>> Hi,
>>
>> "Mulyadi Santosa" <mulyadi.santosa@xxxxxxxxx> writes:
>>
>>> On Thu, Jun 12, 2008 at 7:23 PM, jasjit singh <singh.jasjit@xxxxxxxxxxx> wrote:
>>>>
>>>> My question is how I can decipher the constant values that are added to
>>>> (perhaps) function pointers.
>>>> e.g  412 in {chrdev_open+412}.
>>>
>>> that's...IIRC.... the offset from the beginning of function.
>>>
>>>> Can these figures be actually helpful in getting what exactly caused kernel
>>>> to panic ?
>>>
>>> yes, just disassemble your vmlinux file...
>>>
>>
>> If you have you kernel compiled with the debug enabled, then you can
>> do
>>
>> objdump -S vmlinux
>>
>> It will interleave the source with the compiled assembly
>> instructions.  Very easy to locate the problem.
>>
>>
>> Regards,
>> Wenhua
>>
>> --
>> To unsubscribe from this list: send an email with
>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>
>>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux