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.
I accidently answered directly to you first Lei, but please respond
here on the list.
/Per
Thanks,
Lei