From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7491 invoked by alias); 3 Feb 2011 12:34:07 -0000 Received: (qmail 7379 invoked by uid 22791); 3 Feb 2011 12:34:07 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Feb 2011 12:34:02 +0000 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp04.in.ibm.com (8.14.4/8.13.1) with ESMTP id p13CXuuM020758 for ; Thu, 3 Feb 2011 18:03:56 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p13CXuHU3764410 for ; Thu, 3 Feb 2011 18:03:56 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p13CXtGe010852 for ; Thu, 3 Feb 2011 23:33:56 +1100 Received: from in.ibm.com ([9.124.35.71]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p13CXrjI010781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Feb 2011 23:33:55 +1100 Date: Thu, 03 Feb 2011 12:34:00 -0000 From: "K.Prasad" To: Mark Wielaard Cc: Roland McGrath , systemtap@sourceware.org, Stan Cox , dsmith@redhat.com Subject: Re: Failures with exelib.exp testcase (was Re: minutes 2010-08-19) Message-ID: <20110203123353.GC2488@in.ibm.com> Reply-To: prasad@linux.vnet.ibm.com References: <20110119120045.GA2431@in.ibm.com> <1898521794.32834.1295479440812.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <20110120011852.1C1041822E9@magilla.sf.frob.com> <1295521862.4118.5.camel@springer.wildebeest.org> <20110120185339.6FF851807D2@magilla.sf.frob.com> <1295651779.3049.15.camel@springer.wildebeest.org> <20110202121440.GB3524@in.ibm.com> <1296651551.4270.34.camel@springer.wildebeest.org> <20110203050358.GA2488@in.ibm.com> <1296728173.3341.7.camel@springer.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1296728173.3341.7.camel@springer.wildebeest.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q1/txt/msg00200.txt.bz2 On Thu, Feb 03, 2011 at 11:16:13AM +0100, Mark Wielaard wrote: > On Thu, 2011-02-03 at 10:33 +0530, K.Prasad wrote: > > > If at all possible lets try with the simple testcase that you posted > > > earlier. If you could just post the output of that and the generated > > > stap-symbols.h file that would make it a bit easier to analyze what is > > > going on. > > > > Oh yes, I could have done that. > > > > > $ stap -vvv -k -e 'probe > > > process("/home/prasadkr/helloworld").function("print_hw") > > > { printf("0x%x : %s\n", uaddr(), usymdata(uaddr())) }' -c ./helloworld > > > > > > > Please find the output of the above probe pasted below and the contents > > of stap-symbols.h in the attachment. > > > > # stap -v -k -e 'probe > > process("/home/prasadkr/helloworld").function("print_hw") > > { printf("0x%x : %s\n", uaddr(), usymdata(uaddr())) }' -c ./helloworld > > Pass 1: parsed user script and 75 library script(s) using 38528virt/30592res/7872shr kb, in 240usr/0sys/246real ms. > > Pass 2: analyzed script: 1 probe(s), 2 function(s), 4 embed(s), 0 global(s) using 143744virt/33216res/9088shr kb, in 30usr/120sys/194real ms. > > Pass 3: translated to C into "/tmp/staps7Q0qG/stap_17236.c" using 143296virt/32896res/8960shr kb, in 20usr/110sys/129real ms. > > Pass 4: compiled C into "stap_17236.ko" in 2730usr/350sys/3105real ms. > > Pass 5: starting run. > > Hello world > > 0x10000530 : 00000011.plt_call.__libc_start_main@@GLIBC_2.3+0+0x188/0x350 [/home/prasadkr/helloworld] > > hmmm, so the symbol table inside stap-symbols.h looks precisely the same > as before my patch. > > So, I see it doesn't even compile. Which must mean the #ifdef > __powerpc__ is the wrong guard. What should be tested for to see whether > we are compiling on powerpc? > Hi Mark, So as discussed over chat, the __powerpc__ is indeed defined and hence the output with the patch below is unchanged. Thanks, K.Prasad > While we figure that out, you could just try thing unconditionally: > > diff --git a/translate.cxx b/translate.cxx > index fab3da4..a19e598 100644 > --- a/translate.cxx > +++ b/translate.cxx > @@ -5060,13 +5060,13 @@ dump_unwindsyms (Dwfl_Module *m, > } > else > { > -#ifdef __powerpc__ > +//#ifdef __powerpc__ > // ppc64 uses function descriptors in user space > // XXX - actually check this is a legal address in .odp! > if (GELF_ST_TYPE (sym.st_info) == STT_FUNC > && name[0] != '.') > - Dwarf_Addr sym_addr = *((Dwarf_Addr *) sym_addr); > -#endif > + sym_addr = *((Dwarf_Addr *) sym_addr); > +//#endif > if (n > 0) > { > assert (secname != NULL); > > Note that it removes the erronious redeclaration of sym_addr too. > > Cheers, > > Mark >