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

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2011-01-19 at 17:18 -0800, Roland McGrath wrote:
> > > I'm attaching the output of eu-readelf to this mail.
> 
> You always need -S output to make full sense of -s output.
> 
> > > Symbol table [37] '.symtab' contains 75 entries:
> > > 56 local symbols  String table: [38] '.strtab'
> > >  Num:            Value   Size Type    Bind   Vis          Ndx Name
> > > [...]
> > >    61: 0000000010010a70     64 FUNC    GLOBAL DEFAULT       22 print_hw
> > 
> > So, that does match our _stp_symbol entry:
> >    { 0x10010a70, "print_hw" },
> > and is also totally not what we want/need to resolve the address to
> > the symbol name. I am not sure what is going on here.
> 
> I suspect that ...a70 is the fptr address rather than the code address.  I
> think that's what ppc64 has in st_value for STT_FUNC symbols.  AIUI, the
> word at address 0x10010a70 (i.e. the word in the file section+offset
> corresponding to that virtual address) will hold the actual PC address.
> I don't think there is any way other than looking at that stored word
> to retrieve the real PC address for the function.

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?

Cheers,

Mark