Issues with dwarf APIs

Issues with dwarf APIs

[Sharyathi Nagesh]

Hi
     We are facing some problem accessing debug information. We were 
trying to implement a feature in crash so as to display local variable 
information.

We observed that 2 APIs are failing:
1. dwarf_attr_integrate(variable_die, DW_AT_location, &Dwarf_attribute)
or at
2. dwarf_getlocation_addr(&Dwarf_attribute, addr, &expr,len,1)
     addr: Is current Program counter with in the function boundaries , 
without the bias (all the time we are assuming bias to be zero we feel 
it is a safe bet)

case 1: Is failing when the Dwarf_location section is not present
case 2: Is failing even when Dwarf_location Tab is present in the dwarf 
information,

ex:
In function die for pseries_dedicated_idle_sleep (in ppc64)
readelf -wi vmlinux reads:
-------------------------------------
  <2><385581>: Abbrev Number: 96 (DW_TAG_variable)
  1520738     <385582>   DW_AT_name        : cpu
  1520739     <385586>   DW_AT_decl_file   : 1
  1520740     <385587>   DW_AT_decl_line   : 484
  1520741     <385589>   DW_AT_type        : <0x378b77>
  1520742     <38558d>   DW_AT_location    : 0x5f804      (location list)
-------------------------------------
Even with information of DW_AT_location we are not able to fetch the 
location information and dwarf_getlocation_addr() fails, returns 0.
We are using elfutils-0.137 and above.

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

We wanted to know if these results are as expected, we have fallowed 
systemtap most of the time. We also observed that most of the time, 
except the volatile variables, we are having difficulty printing the 
variables.

Went through this link: 
http://sources.redhat.com/systemtap/wiki/TipContextVariables
It looks like systemtap also has faced similar problems


This is the Psuedo-code what we have implemented:
print_variable (Takes 2 Dies function die and variable die)
{
     /* Function DIE is got from PC */
         /* Variable DIE got by going through the child DIEs */
     dwarf_attr_integrate(var_die, DW_AT_location, Dwarf_Attribute)
     dwarf_getlocation_addr(Dwarf_Attribute, Program_Counter,*);

     /*It is failing in one of the above APIs
}

I can provide a more detailed code walk through, if wish to
Can you please help us with this
Thanks
Yeehaw

Re: Issues with dwarf APIs

[Frank Ch. Eigler]

Hi -

> [...]
> 2. dwarf_getlocation_addr(&Dwarf_attribute, addr, &expr,len,1)
>     addr: Is current Program counter with in the function boundaries , 
> [...]
> case 2: Is failing even when Dwarf_location Tab is present in the dwarf 
> [...]
> In function die for pseries_dedicated_idle_sleep (in ppc64)
> readelf -wi vmlinux reads:
> -------------------------------------
>  <2><385581>: Abbrev Number: 96 (DW_TAG_variable)
>  1520738     <385582>   DW_AT_name        : cpu
>  1520739     <385586>   DW_AT_decl_file   : 1
>  1520740     <385587>   DW_AT_decl_line   : 484
>  1520741     <385589>   DW_AT_type        : <0x378b77>
>  1520742     <38558d>   DW_AT_location    : 0x5f804      (location list)
> [...]

Check out the location list contents (0x5f804).  Most likely the
address you supplied to dwarf_getlocation_addr is not within the range
of addresses that were encoded.  This could mean that the variable is
only partially in scope, or that at that particular moment (PC value),
it had no easily encoded location.

Be sure you're using the right PC.  If you're doing backtracing, your
PC value will only rarely happen to be the entry address of a
function; more frequently it will be in the middle (at a function call
site).

- FChE

Re: Issues with dwarf APIs

[Roland McGrath]

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

Re: 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

Re: Issues with dwarf APIs

[Roland McGrath]

>     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.

Yes, you have to use the correct exact PC that was stored for that stack frame.
The DWARF info describes how to find a symbolic value in the context of an
exact PC.  For some PC elsewhere in the function, the details may differ hugely.