Hi,
On Tue, Mar 5, 2013 at 9:22 AM, Lei Wen <adrian.wenl(a)gmail.com> wrote:
Per,
On Tue, Mar 5, 2013 at 3:25 PM, Per Fransson <per.fransson.ml(a)gmail.com> wrote:
> Hi Lei,
>
> On Tue, Mar 5, 2013 at 1:22 AM, Lei Wen <adrian.wenl(a)gmail.com> wrote:
>> Hi Per,
>>
>>
>> On Tue, Mar 5, 2013 at 4:38 AM, Per Fransson <per.fransson.ml(a)gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Mar 4, 2013 at 8:49 PM, Mika Westerberg
<mika.westerberg(a)iki.fi>
>>> wrote:
>>> > On Mon, Mar 04, 2013 at 10:20:42AM +0800, Lei Wen wrote:
>>> >> I met "dis" command not correct issue when use the crash,
any idea?
>>> >> For built-in "dis" command in crash:
>>> >> crash> dis task_rq_lock
>>> >> 0xc015a2d8 <task_rq_lock>: rscsgt r0, sp, r3, lsl #14
>>> >> 0xc015a2dc <task_rq_lock+4>: mrcgt 8, 7, r0, cr2, cr13,
{5}
>>> >> 0xc015a2e0 <task_rq_lock+8>: mcrvc 8, 4, r3, cr13, cr3,
{6}
>>> >> 0xc015a2e4 <task_rq_lock+12>: lslsvc r3, r10, r8
>>> >> 0xc015a2e8 <task_rq_lock+16>: bl 0xc049fe34
>>> >> <__ip_route_output_key+220>
>>> >
>>> > Looks weird.
>>> >
>>> > What is the kernel version? Does the 'dis' command work for
other
>>> > functions?
>>> >
>>>
>>> You could do a check on one of the instructions - the 'bl' comes to
>>> mind. Not sure, but I believe it should amount to:
>>>
>>> 0xeb000000 | (((0xc049fe34-0xc015a2f0) >> 2) & 0x00ffffff)
>>>
>>> i.e.
>>>
>>> 0xeb0d16d1
>>>
>>> Is that what you get with
>>>
>>> crash> rd 0xc015a2e8
>>>
>>> ?
>>>
>>> If not, try a
>>>
>>> crash> search 0xeb0d16d1
>>>
>>> and see if it turns up somewhere else.
>>
>>
>>
>>
>> Yes, it is that value.
>>
>> crash> rd 0xc015a2e8
>>
>> c015a2e8: eb0d16d1 ....
>>
>>
>>
>> While in gdb, show the same address's value, it would be:
>>
>> (gdb) x 0xc015a2e8
>>
>> 0xc015a2e8 <task_rq_lock+16>: 0xe1a05000
>>
>>
>>
>> Why it didn't match with each other? Any idea?
>>
>>
>
> Nope, no idea. When you're using gdb, do you feed it the coredump as
> well, or just the vmlinux? if you get the same strange result with
> gdb+vmlinux+coredump, I think you should try to match some known data,
> e.g. the 'bl' and see if the contents are offset somehow. Try the gdb
> search command on 0xeb0d16d1.
Your hypothesis is correct.
When feed dump image with vmlinux to the gdb, I get exactly same result
as crash...
How to use the search command in gdb?
Oh, it's 'find' in gdb. To look for 0xeb0d16d1 in the virtual interval
0xc0000000--0xe0000000 you would:
(gdb) find /w 0xc0000000, +0x20000000, 0xeb0d16d1
or use your favorite hex editor.
If the dump isn't offset, it could be overwrites.
/Per
Thanks,
Lei