Issues with dwarf APIs

[Sharyathi Nagesh]

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