----- Original Message ----- > > > Hi, > > 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> > > > But if I use arm-none-linux-gnueabi-gdb to load the vmlinux and do > the disassemble job, I would see: > > (gdb) disas task_rq_lock > Dump of assembler code for function task_rq_lock: > 0xc015a2d8 <+0>: push {r4, r5, r6, r7, r8, r10, r11, lr} > 0xc015a2dc <+4>: add r7, r0, #620 ; 0x26c > 0xc015a2e0 <+8>: ldr r6, [pc, #100] ; 0xc015a34c <task_rq_lock+116> > 0xc015a2e4 <+12>: add r11, sp, #28 > 0xc015a2e8 <+16>: mov r5, r0 > > Thanks, > Lei In architecture-specific cases such as this, please put "ARM" predominantly in the Subject line so as to catch the attention of the ARM maintainers on this list. I can't help w/respect to running a native version of ARM, and I can't reproduce the above with the sample ARM vmcores that I have on hand. But using a crash binary built with "make target=ARM" on an x86_64 host, I see this: # crash vmlinux vmcore ... [ cut ] ... GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-elf-linux"... ... And with --target=arm-elf-linux, I see these results: 2.6.35: crash> dis task_rq_lock 0xc004cd80 <task_rq_lock>: push {r4, r5, r11, lr} 0xc004cd84 <task_rq_lock+4>: add r11, sp, #12 0xc004cd88 <task_rq_lock+8>: mrs r3, CPSR 0xc004cd8c <task_rq_lock+12>: cpsid i 0xc004cd90 <task_rq_lock+16>: ldr r4, [pc, #20] ; 0xc004cdac <task_rq_lock+44> 0xc004cd94 <task_rq_lock+20>: str r3, [r1] 0xc004cd98 <task_rq_lock+24>: bl 0xc0073980 <trace_hardirqs_off> 0xc004cd9c <task_rq_lock+28>: mov r0, r4 0xc004cda0 <task_rq_lock+32>: bl 0xc028c898 <_raw_spin_lock> 0xc004cda4 <task_rq_lock+36>: mov r0, r4 0xc004cda8 <task_rq_lock+40>: pop {r4, r5, r11, pc} 0xc004cdac <task_rq_lock+44>: eorsgt r6, r9, r8, ror r12 crash> 2.6.36: crash> dis task_rq_lock 0xc01e69d8 <task_rq_lock>: push {r3, r4, r5, r6, r7, r8, r11, lr} 0xc01e69dc <task_rq_lock+4>: add r11, sp, #28 0xc01e69e0 <task_rq_lock+8>: mov r5, r0 0xc01e69e4 <task_rq_lock+12>: mov r4, r1 0xc01e69e8 <task_rq_lock+16>: mrs r3, CPSR 0xc01e69ec <task_rq_lock+20>: cpsid i 0xc01e69f0 <task_rq_lock+24>: str r3, [r4] 0xc01e69f4 <task_rq_lock+28>: ldr r3, [r5, #4] 0xc01e69f8 <task_rq_lock+32>: ldr r8, [pc, #68] ; 0xc01e6a44 <task_rq_lock+108> 0xc01e69fc <task_rq_lock+36>: ldr r7, [pc, #68] ; 0xc01e6a48 <task_rq_lock+112> 0xc01e6a00 <task_rq_lock+40>: ldr r3, [r3, #20] 0xc01e6a04 <task_rq_lock+44>: ldr r6, [r8, r3, lsl #2] 0xc01e6a08 <task_rq_lock+48>: add r6, r7, r6 0xc01e6a0c <task_rq_lock+52>: mov r0, r6 0xc01e6a10 <task_rq_lock+56>: bl 0xc033dc40 <_raw_spin_lock> 0xc01e6a14 <task_rq_lock+60>: ldr r3, [r5, #4] 0xc01e6a18 <task_rq_lock+64>: ldr r3, [r3, #20] 0xc01e6a1c <task_rq_lock+68>: ldr r3, [r8, r3, lsl #2] 0xc01e6a20 <task_rq_lock+72>: add r7, r7, r3 0xc01e6a24 <task_rq_lock+76>: cmp r6, r7 0xc01e6a28 <task_rq_lock+80>: bne 0xc01e6a34 <task_rq_lock+92> 0xc01e6a2c <task_rq_lock+84>: mov r0, r6 0xc01e6a30 <task_rq_lock+88>: pop {r3, r4, r5, r6, r7, r8, r11, pc} 0xc01e6a34 <task_rq_lock+92>: mov r0, r6 0xc01e6a38 <task_rq_lock+96>: ldr r1, [r4] 0xc01e6a3c <task_rq_lock+100>: bl 0xc033d7b0 <_raw_spin_unlock_irqrestore> 0xc01e6a40 <task_rq_lock+104>: b 0xc01e69e8 <task_rq_lock+16> 0xc01e6a44 <task_rq_lock+108>: subgt r7, r2, r8 0xc01e6a48 <task_rq_lock+112>: andsgt r2, sp, r0, lsr #18 crash> 2.6.38: crash> dis task_rq_lock 0xc0084864 <task_rq_lock>: push {r3, r4, r5, r6, r7, r8, r11, lr} 0xc0084868 <task_rq_lock+4>: mov r5, r0 0xc008486c <task_rq_lock+8>: add r11, sp, #28 0xc0084870 <task_rq_lock+12>: mov r4, r1 0xc0084874 <task_rq_lock+16>: mrs r3, CPSR 0xc0084878 <task_rq_lock+20>: cpsid i 0xc008487c <task_rq_lock+24>: str r3, [r4] 0xc0084880 <task_rq_lock+28>: bl 0xc00be9a8 <trace_hardirqs_off> 0xc0084884 <task_rq_lock+32>: ldr r3, [r5, #4] 0xc0084888 <task_rq_lock+36>: ldr r8, [pc, #68] ; 0xc00848d4 <task_rq_lock+112> 0xc008488c <task_rq_lock+40>: ldr r7, [pc, #68] ; 0xc00848d8 <task_rq_lock+116> 0xc0084890 <task_rq_lock+44>: ldr r3, [r3, #20] 0xc0084894 <task_rq_lock+48>: ldr r6, [r8, r3, lsl #2] 0xc0084898 <task_rq_lock+52>: add r6, r7, r6 0xc008489c <task_rq_lock+56>: mov r0, r6 0xc00848a0 <task_rq_lock+60>: bl 0xc03f1500 <_raw_spin_lock> 0xc00848a4 <task_rq_lock+64>: ldr r3, [r5, #4] 0xc00848a8 <task_rq_lock+68>: ldr r3, [r3, #20] 0xc00848ac <task_rq_lock+72>: ldr r3, [r8, r3, lsl #2] 0xc00848b0 <task_rq_lock+76>: add r7, r7, r3 0xc00848b4 <task_rq_lock+80>: cmp r6, r7 0xc00848b8 <task_rq_lock+84>: bne 0xc00848c4 <task_rq_lock+96> 0xc00848bc <task_rq_lock+88>: mov r0, r6 0xc00848c0 <task_rq_lock+92>: pop {r3, r4, r5, r6, r7, r8, r11, pc} 0xc00848c4 <task_rq_lock+96>: mov r0, r6 0xc00848c8 <task_rq_lock+100>: ldr r1, [r4] 0xc00848cc <task_rq_lock+104>: bl 0xc03f1ae4 <_raw_spin_unlock_irqrestore> 0xc00848d0 <task_rq_lock+108>: b 0xc0084874 <task_rq_lock+16> 0xc00848d4 <task_rq_lock+112>: subsgt r12, r8, r12, asr #28 0xc00848d8 <task_rq_lock+116>: andgt pc, r4, r0, lsl #2 crash> But in 3.1.1, the "task_rq_lock" function is renamed to "task_rq_lock.isra.123": crash> dis task_rq_lock symbol not found: task_rq_lock possible alternatives: c0015c60 (t) task_rq_lock.isra.123 crash> which is also reflected in the vmlinux file: crash> !nm -Bn vmlinux | grep task_rq_lock c0015c60 t task_rq_lock.isra.123 crash> I don't know what "isra" means, but it disassembles OK when used like this: crash> dis task_rq_lock.isra.123 0xc0015c60 <task_rq_lock.isra.123>: push {r11, lr} 0xc0015c64 <task_rq_lock.isra.123+4>: add r11, sp, #4 0xc0015c68 <task_rq_lock.isra.123+8>: mrs r3, CPSR 0xc0015c6c <task_rq_lock.isra.123+12>: orr r2, r3, #128 ; 0x80 0xc0015c70 <task_rq_lock.isra.123+16>: msr CPSR_c, r2 0xc0015c74 <task_rq_lock.isra.123+20>: str r3, [r0] 0xc0015c78 <task_rq_lock.isra.123+24>: mov r0, #1 0xc0015c7c <task_rq_lock.isra.123+28>: bl 0xc0015ba4 <add_preempt_count> 0xc0015c80 <task_rq_lock.isra.123+32>: mov r0, #1 0xc0015c84 <task_rq_lock.isra.123+36>: bl 0xc0015ba4 <add_preempt_count> 0xc0015c88 <task_rq_lock.isra.123+40>: ldr r0, [pc, #0] ; 0xc0015c90 <task_rq_lock.isra.123+48> 0xc0015c8c <task_rq_lock.isra.123+44>: pop {r11, pc} 0xc0015c90 <task_rq_lock.isra.123+48>: eorsgt lr, r12, r0, asr r2 crash> And interestingly enough, gdb accepts the symbol without the "isra.123", strips it from the text symbol, and it looks like this: crash> disass task_rq_lock Dump of assembler code for function task_rq_lock: 0xc0015c60 <+0>: push {r11, lr} 0xc0015c64 <+4>: add r11, sp, #4 0xc0015c68 <+8>: mrs r3, CPSR 0xc0015c6c <+12>: orr r2, r3, #128 ; 0x80 0xc0015c70 <+16>: msr CPSR_c, r2 0xc0015c74 <+20>: str r3, [r0] 0xc0015c78 <+24>: mov r0, #1 0xc0015c7c <+28>: bl 0xc0015ba4 <add_preempt_count> 0xc0015c80 <+32>: mov r0, #1 0xc0015c84 <+36>: bl 0xc0015ba4 <add_preempt_count> 0xc0015c88 <+40>: ldr r0, [pc, #0] ; 0xc0015c90 <task_rq_lock+48> 0xc0015c8c <+44>: pop {r11, pc} 0xc0015c90 <+48>: eorsgt lr, r12, r0, asr r2 End of assembler dump. crash> Can the ARM maintainers shed some light on this? I suppose that the when the crash utility's "dis" command fails to find an ARM symbol, but there is one that has ".isra.###" appended, that it could strip it and use its address? In the one 3.1.1 ARM kernel I have, there are 282 of these "isra" text symbols. That being said, I have no clue as to what's happening in your case. Dave

On Mon, Mar 04, 2013 at 10:17:26AM -0500, Dave Anderson wrote: > But in 3.1.1, the "task_rq_lock" function is renamed to > "task_rq_lock.isra.123": > > crash> dis task_rq_lock > symbol not found: task_rq_lock > possible alternatives: > c0015c60 (t) task_rq_lock.isra.123 > crash> > > which is also reflected in the vmlinux file: > > crash> !nm -Bn vmlinux | grep task_rq_lock > c0015c60 t task_rq_lock.isra.123 > crash> > > I don't know what "isra" means, but it disassembles OK when used > like this: > > crash> dis task_rq_lock.isra.123 > 0xc0015c60 <task_rq_lock.isra.123>: push {r11, lr} > 0xc0015c64 <task_rq_lock.isra.123+4>: add r11, sp, #4 > 0xc0015c68 <task_rq_lock.isra.123+8>: mrs r3, CPSR > 0xc0015c6c <task_rq_lock.isra.123+12>: orr r2, r3, #128 ; > 0x80 > 0xc0015c70 <task_rq_lock.isra.123+16>: msr CPSR_c, r2 > 0xc0015c74 <task_rq_lock.isra.123+20>: str r3, [r0] > 0xc0015c78 <task_rq_lock.isra.123+24>: mov r0, #1 > 0xc0015c7c <task_rq_lock.isra.123+28>: bl 0xc0015ba4 > <add_preempt_count> > 0xc0015c80 <task_rq_lock.isra.123+32>: mov r0, #1 > 0xc0015c84 <task_rq_lock.isra.123+36>: bl 0xc0015ba4 > <add_preempt_count> > 0xc0015c88 <task_rq_lock.isra.123+40>: ldr r0, [pc, #0] ; > 0xc0015c90 <task_rq_lock.isra.123+48> > 0xc0015c8c <task_rq_lock.isra.123+44>: pop {r11, pc} > 0xc0015c90 <task_rq_lock.isra.123+48>: eorsgt lr, r12, r0, asr > r2 > crash> > > And interestingly enough, gdb accepts the symbol without the > "isra.123", > strips it from the text symbol, and it looks like this: > > crash> disass task_rq_lock > Dump of assembler code for function task_rq_lock: > 0xc0015c60 <+0>: push {r11, lr} > 0xc0015c64 <+4>: add r11, sp, #4 > 0xc0015c68 <+8>: mrs r3, CPSR > 0xc0015c6c <+12>: orr r2, r3, #128 ; 0x80 > 0xc0015c70 <+16>: msr CPSR_c, r2 > 0xc0015c74 <+20>: str r3, [r0] > 0xc0015c78 <+24>: mov r0, #1 > 0xc0015c7c <+28>: bl 0xc0015ba4 <add_preempt_count> > 0xc0015c80 <+32>: mov r0, #1 > 0xc0015c84 <+36>: bl 0xc0015ba4 <add_preempt_count> > 0xc0015c88 <+40>: ldr r0, [pc, #0] ; 0xc0015c90 > <task_rq_lock+48> > 0xc0015c8c <+44>: pop {r11, pc} > 0xc0015c90 <+48>: eorsgt lr, r12, r0, asr r2 > End of assembler dump. > crash> Dave, it looks like those symbols exist in x86_64 kernel images as well. Are you able to run 'dis' over some of those symbols on x86_64? I wonder if we have more generic problem at hand.

On Tue, Mar 05, 2013 at 08:58:58AM -0500, Dave Anderson wrote: > I'm thinking that it's probably best that the ".isra..." should be stripped > during the symbol storage phase so that the crash sources have no idea > that they ever existed with those names. The module symbol storage code has > always done a similar thing in strip_module_symbol_end(). > > And the gdb module must be doing the same kind of thing, because you can pass > the "stripped" symbol name to gdb, and it knows what it is: > > crash> dis get_sigframe > symbol not found: get_sigframe > possible alternatives: > ffffffff81058090 (t) get_sigframe.isra.1 > crash> > > crash> disass get_sigframe > Dump of assembler code for function get_sigframe: > 0xffffffff81058090 <+0>: nopl 0x0(%rax,%rax,1) > 0xffffffff81058095 <+5>: push %rbp > 0xffffffff81058096 <+6>: mov %rsp,%rbp > 0xffffffff81058099 <+9>: push %rbx > 0xffffffff8105809a <+10>: mov %rdx,%rbx > 0xffffffff8105809d <+13>: sub $0x18,%rsp > ... > > Anyway, I'll take care of that. Great, thanks. One more thing - it looks like there are other "cloning symbols" in addition to .isra... you can find the list here: http://gcc.gnu.org/viewcvs/trunk/libiberty/testsuite/demangle-expected?re... (find comment saying "Clone suffix tests"). Maybe we should handle them as well?

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>

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.