Re: [Crash-utility] dis command not correct in crash

Hi, On Tue, Mar 5, 2013 at 9:22 AM, Lei Wen <adrian.wenl(a)gmail.com&gt; wrote: > Per, > > On Tue, Mar 5, 2013 at 3:25 PM, Per Fransson <per.fransson.ml(a)gmail.com&gt; wrote: >> Hi Lei, >> >> On Tue, Mar 5, 2013 at 1:22 AM, Lei Wen <adrian.wenl(a)gmail.com&gt; wrote: >>> Hi Per, >>> >>> >>> On Tue, Mar 5, 2013 at 4:38 AM, Per Fransson <per.fransson.ml(a)gmail.com&gt; >>> wrote: >>>> >>>> Hi, >>>> >>>> On Mon, Mar 4, 2013 at 8:49 PM, Mika Westerberg <mika.westerberg(a)iki.fi&gt; >>>> 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.