On Sat, Jan 22, 2011 at 12:16:19AM +0100, Mark Wielaard wrote:
> On Thu, 2011-01-20 at 10:53 -0800, Roland McGrath wrote:
> > > Aha. Thanks. I now remember we dealt with this somehow for the kernel
> > > addresses: http://sourceware.org/bugzilla/show_bug.cgi?id=10206
> > > Although reading your explanation now I don't understand why that
> > > actually worked, since we don't have any special code to resolve such
> > > addresses in translate.cxx, we always just store the st_value as sym
> > > address (possibly adjusted with dwfl_module_relocate_address). Is there
> > > something special about powerpc user code symbols that make it different
> > > from kernel code symbols?
> > 
> > I'm no ppc64 expert, but I've just now looked at the symbol tables of a
> > ppc64 kernel and a random ppc64 user executable.  
> > 
> > In the kernel, there is both an STT_FUNC symbol named ".foo" whose st_value
> > is the actual code address, and an STT_NOTYPE symbol named "foo" whose
> > st_value is the address in the .opd section (the function descriptor
> > address).
> > 
> > In the user executable, there is only one symbol for a function still left
> > after the final link, an STT_FUNC symbol named "foo" whose st_value is the
> > address in the .opd section.
> > 
> > So I would surmise that what happens in systemtap in the kernel case is
> > that it finds the ".foo" symbol and is happy with that, and ppc64 users
> > just ignore the leading . when reading the output.  In the user case, there
> > is no symbol at all whose value is the code address, so there is no match.
> 
> That explains why we have all these "." suppression stuff around in the
> runtime and tapsets:
> 
> #ifdef __powerpc__
>   // Map ".sys_foo" to "sys_foo".
>   if (name[0] == '.')
>     name++;
> #endif
> 
> Strangely enough we have symbol table parsing code in both tapsets.cxx,
> which handles the special case powerpc .odp section and the function
> description setup, responsible for calculating the addresses to set
> probes on, and totally separate symbol table parsing code in
> translate.cxx, responsible for writing the lookup table we use at
> runtime, that doesn't have any special case powerpc (except for that one
> bit where it accepts symbols with STT_NOTYPE).
> 
> It would be nice to merge these one day. Although the tapsets.cxx one
> does exactly the opposite from what we want in translate.cxx:
> 
> /*
>  * The .opd section contains function descriptors that can look
>  * just like function entry points.  For example, there's a function
>  * descriptor called "do_exit" that links to the entry point ".do_exit".
>  * Reject all symbols in .opd.
>  */
> 
> Maybe this is a little too naive, but would it be as simple as the
> attached? I don't actually have any powerpc machine to check.
> 
> Cheers,
> 
> Mark

Hi,
  I haven't really gone through the patch yet but tested them on a ppc64
box and the tests still seem to fail (the output of systemtap.log of a
partial testsuite run is attached).

Thanks,
K.Prasad