Re: Failures with exelib.exp testcase (was Re: minutes 2010-08-19)

[Roland McGrath <roland at redhat dot com>]

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


Thanks,
Roland