dear john,
> > > Also, look up the file offset of the .text section with objdump -h. If
> > > you add, or subtract, that value from/to the vma, do you get anything
> > > saner?
> > The offset to the .text section is 0 (its the first section), so it
>
> There must at least be some offset, there's an ELF header first :)
I am sorry, objdump -h gave me:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00380000 c000000000000000 c000000000000000 00010000 2**8
CONTENTS, ALLOC, LOAD, READONLY, CODE
I was wrong. You meant the File offset which is reasonable.
Adding 0x10000 to 0x2b3138 points to the code:
c0000000002a3138: 40 a2 ff f4 bne- c0000000002a312c
<.matroxfb_ioc\tl+0x608>
c0000000002a313c: 4c 00 01 2c isync
c0000000002a3140: 7c 00 07 b4 extsw r0,r0
c0000000002a3144: 2f 80 ff ff cmpwi cr7,r0,-1
c0000000002a3148: 41 9c 06 d8 blt- cr7,c0000000002a3820
<.matroxfb\_ioctl+0xcfc>
c0000000002a314c: 2f 9a 00 00 cmpwi cr7,r26,0
Subtracting it leads to:
c0000000002c3138 <.power4_reg_setup>:
c0000000002c3138: 7c 1f 42 a6 mfpvr r0
c0000000002c313c: 78 09 84 22 rldicl r9,r0,48,48
c0000000002c3140: fb c1 ff f0 std r30,-16(r1)
We have another idea what may lead to the unexpected
unknown_kernel_bucket, even if not in that dimension. If oprofile
looks which binary image is executing actually and the pointer to the
code points to firmware code, it cant decide correct?
Am i right that if executing code that is prior to the kernel image in
ram (openfirmware code), we will see unknown_kernel_bucket symbol? I
am not sure why i see the strange sourcefile then
(op_model_power4.c:64).
thank you
joerg
|