This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Issues with dwarf APIs


Thanks Roland and Frank for providing the guidance
Regarding the PC, this is definitely not the entry address of the function but the return location from the called function, hence it is between low_pc and high_pc. As I understand that is the right thing to do, giving low_pc or starting address of the function had issues with variable not getting initialized at that instance.


Roland as I understand the variable is still in scope, so I think this needs to be taken up with the gcc, mailing list. Thanks a lot for the input
Thanks
Yeehaw


--------------------------------------------------------
Objdump value:

 static void pseries_dedicated_idle_sleep(void)
 520 {
 521         unsigned int cpu = smp_processor_id();
 522  330:   a3 ed 00 0a     lhz     r31,10(r13)
 523 /home/mohan/linux-2.6.27/arch/powerpc/platforms/pseries/setup.c:492
			<== cpu is stored in r31

Function Disassemble code

crash> disassemble pseries_dedicated_idle_sleep
Dump of assembler code for function pseries_dedicated_idle_sleep:
0xc00000000003b038 <pseries_dedicated_idle_sleep+0>: mflr r0
0xc00000000003b03c <pseries_dedicated_idle_sleep+4>: std r24,-64(r1)
0xc00000000003b040 <pseries_dedicated_idle_sleep+8>: std r25,-56(r1)
0xc00000000003b044 <pseries_dedicated_idle_sleep+12>: std r26,-48(r1)
0xc00000000003b048 <pseries_dedicated_idle_sleep+16>: std r27,-40(r1)
0xc00000000003b04c <pseries_dedicated_idle_sleep+20>: std r28,-32(r1)
0xc00000000003b050 <pseries_dedicated_idle_sleep+24>: std r29,-24(r1)
0xc00000000003b054 <pseries_dedicated_idle_sleep+28>: std r0,16(r1)
0xc00000000003b058 <pseries_dedicated_idle_sleep+32>: std r30,-16(r1)
0xc00000000003b05c <pseries_dedicated_idle_sleep+36>: std r31,-8(r1)
0xc00000000003b060 <pseries_dedicated_idle_sleep+40>: stdu r1,-176(r1)
0xc00000000003b064 <pseries_dedicated_idle_sleep+44>: li r0,1
0xc00000000003b068 <pseries_dedicated_idle_sleep+48>: ld r9,0(r13)
0xc00000000003b06c <pseries_dedicated_idle_sleep+52>: lhz r31,10(r13)
<== cpu is pointed by reg 31
0xc00000000003b070 <pseries_dedicated_idle_sleep+56>: stb r0,254(r9)
0xc00000000003b074 <pseries_dedicated_idle_sleep+60>: ld r9,0(r13)
0xc00000000003b078 <pseries_dedicated_idle_sleep+64>: stb r0,185(r9)
0xc00000000003b07c <pseries_dedicated_idle_sleep+68>: mfspr r24,309
0xc00000000003b080 <pseries_dedicated_idle_sleep+72>: ld r0,48(r13)
0xc00000000003b084 <pseries_dedicated_idle_sleep+76>: ld r9,-27576(r2)
0xc00000000003b088 <pseries_dedicated_idle_sleep+80>: ldx r10,r9,r0
0xc00000000003b08c <pseries_dedicated_idle_sleep+84>: cmpdi cr7,r10,0
0xc00000000003b090 <pseries_dedicated_idle_sleep+88>: beq- cr7,0xc00000000003b184
<pseries_dedicated_idle_sleep+332>
0xc00000000003b094 <pseries_dedicated_idle_sleep+92>: mftb r11
0xc00000000003b098 <pseries_dedicated_idle_sleep+96>: ld r9,-27568(r2)
0xc00000000003b09c <pseries_dedicated_idle_sleep+100>: ld r0,0(r9)
0xc00000000003b0a0 <pseries_dedicated_idle_sleep+104>: mulld r0,r10,r0
0xc00000000003b0a4 <pseries_dedicated_idle_sleep+108>: add r26,r0,r11
0xc00000000003b0a8 <pseries_dedicated_idle_sleep+112>: bl 0xc0000000000b36d4 <tra
ce_hardirqs_on>
0xc00000000003b0ac <pseries_dedicated_idle_sleep+116>: nop
<== Current Program Counter is Here
<== r31 is not modified after
0xc00000000003b06c
--------------------------------------------------------



Roland McGrath wrote:
elfutils-devel@lists.fedorahosted.org is the list for the elfutils libraries.

Even with information of DW_AT_location we are not able to fetch the location information and dwarf_getlocation_addr() fails, returns 0.

"returns 0" != "fails"


From libdw.h:

			       A return value of zero means that the
   location list indicated no value is accessible.  */

This is a successful call telling you that there are zero locations to be had.

In this particular case gdb also fails to print cpu value and instead says the value is optimized out.

They are reporting the same truth: the compiler said that this value was not available at that PC. If you read the disassembly and think the value should in fact be available in some register or memory location at the PC in question, then you need to pursue a compiler bug report about that.


Thanks, Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]