1:14 p.m.
----- "Bryn M. Reeves" <bmr(a)redhat.com> wrote:
Hi Folks,
I have some experience using crash on x86/x86_64 cores but I'm pretty
new to ppc64. I'm making some headway, but a bit confused by some
things.
E.g., I have a function that calls kfree, so when I disassemble it,
I'm expecting to see something like:
bl <address of .kfree>
But instead I find:
0xd000000000bd3b00 bl 0xd000000000bd4120
Where that address lies inside .init_module:
crash> sym 0xd000000000bd4120
d000000000bd4120 (T) .init_module+496
.kfree is somewhere else entirely:
crash> sym .kfree
c0000000000ed0b4 (T) .kfree
I'm pretty certain this is the call to kfree that I'm interested in
(LR points at the next instruction and we oopsed inside kfree).
Is there some sort of indirection here that I'm missing?
Apparently so, at least with respect to kernel module code calling into
the base kernel. Here's a call to kmalloc() in ext3_xattr_block_set(),
where kmalloc() is actually an inline in slab.h that calls __kmalloc():
crash> dis -l .ext3_xattr_block_set
...
/usr/src/debug/kernel-2.6.18/linux-2.6.18.ppc64/fs/ext3/xattr.c: 724
0xd00000000019671c <.ext3_xattr_block_set+548>: ld r9,40(r26)
include/linux/slab.h: 154
0xd000000000196720 <.ext3_xattr_block_set+552>: li r4,208
0xd000000000196724 <.ext3_xattr_block_set+556>: ld r3,32(r9)
0xd000000000196728 <.ext3_xattr_block_set+560>: bl 0xd000000000199858
...
and looking around that "bl" target, there's the target function
address of ".__kmalloc" a few words after it:
crash> rd -s 0xd000000000199858 20
d000000000199858: 3d82fffe398ce448 f8410028e96c0020
d000000000199868: e84c00287d6903a6 4e80042000000000
d000000000199878: .__kmalloc PPC64_CACHES+24336
d000000000199888: 3d82fffe398ce478 f8410028e96c0020
d000000000199898: e84c00287d6903a6 4e80042000000000
d0000000001998a8: .memset PPC64_CACHES+24336
d0000000001998b8: 3d82fffe398ce4a8 f8410028e96c0020
d0000000001998c8: e84c00287d6903a6 4e80042000000000
d0000000001998d8: .memcpy PPC64_CACHES+24336
d0000000001998e8: 3d82fffe398ce4d8 f8410028e96c0020
crash>
So I presume if you look at the data around 0xd000000000bd4120, you'll
most likely see ".kfree".
Dave
1:34 p.m.
New subject: crash on ppc docs / pointers
Dave Anderson wrote:
and looking around that "bl" target, there's the target
function
address of ".__kmalloc" a few words after it:
crash> rd -s 0xd000000000199858 20 d000000000199858:
3d82fffe398ce448 f8410028e96c0020 d000000000199868:
e84c00287d6903a6 4e80042000000000 d000000000199878: .__kmalloc
PPC64_CACHES+24336 d000000000199888: 3d82fffe398ce478
f8410028e96c0020 d000000000199898: e84c00287d6903a6
4e80042000000000 d0000000001998a8: .memset
PPC64_CACHES+24336 d0000000001998b8: 3d82fffe398ce4a8
f8410028e96c0020 d0000000001998c8: e84c00287d6903a6
4e80042000000000 d0000000001998d8: .memcpy
PPC64_CACHES+24336 d0000000001998e8: 3d82fffe398ce4d8
f8410028e96c0020 crash>
So I presume if you look at the data around 0xd000000000bd4120,
you'll most likely see ".kfree".
Ah-ha! Thanks Dave! I wondered if it was something like this and did
poke around a bit in the words following 0xd000000000bd4120 (stupidly
with dis rather than rd which was getting a bit confused and only
outputting one word at a time as I manually advanced the address..).
I didn't go quite far enough to see this:
crash> rd 0xd000000000bd4120 16
d000000000bd4120: 3d82ffff398cd3a0 f8410028e96c0020 =...9....A.(.l.
d000000000bd4130: e84c00287d6903a6 4e80042000000000 .L.(}i..N.. ....
d000000000bd4140: c0000000000ed0b4 [...]
crash> sym .kfree
c0000000000ed0b4 (T) .kfree
Thanks again.
Cheers,
Bryn.
5605
days inactive
5605
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Bryn M. Reeves -
Dave Anderson