This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Issues with dwarf APIs
- From: Sharyathi Nagesh <sharyath at in dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>, fche at elastic dot org
- Cc: systemtap at sources dot redhat dot com, Mohan Kumar M <mohan at in dot ibm dot com>
- Date: Thu, 04 Jun 2009 02:43:56 +0530
- Subject: Re: Issues with dwarf APIs
- References: <4A248804.3070009@in.ibm.com> <20090602225829.E2C97FC3C7@magilla.sf.frob.com>
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