[Bug runtime/12566] usymbols.exp 64-bit test failing on ppc64

["mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12566

Mark Wielaard <mjw at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjw at redhat dot com

--- Comment #2 from Mark Wielaard <mjw at redhat dot com> 2011-03-11 21:29:16 UTC ---
(In reply to comment #1)
> In the 64-bit case (which fails):
> 
> # eu-readelf -s usymbols-m64  | fgrep main_handler
>    63: 0000000010010c48     16 FUNC    GLOBAL DEFAULT       22 main_handler
> # fgrep main_handler /tmp/stapImPRwN/stap-symbols.h 
>   { 0x10010c48, "main_handler" },
> 
> That's good, the eu-readelf and stap values match.
> 
> When run under gb,
> (gdb) p &main_handler
> $1 = (void (*)(int)) 0x10000700 <main_handler>
> 
> That's bad - when run, somehow the address has changed.
> 
> # fgrep /usymbols-m64 /proc/9183/maps 
> 10000000-10010000 r-xp 00000000 fd:00 2239236                           
> /root/ppc64/testsuite/usymbols-m64
> 10010000-10020000 rw-p 00000000 fd:00 2239236                           
> /root/ppc64/testsuite/usymbols-m64
> 
> The 0x10010c48 address exists within that 2nd non-executable vma (the code in
> vma.c only looks at executable vmas), which is why the symbol lookup code
> fails.  The gdb address (0x10000700) does exist within the 1st executable vma.
> 
> Perhaps there is some relocation going on that systemtap needs to know about.

The 0x10010c48 address is a pointer into the .odp table. So it is an indirect
address to the real function address. We had a little discussion on making
systemtap deal with that better on the mailinglist:
http://sourceware.org/ml/systemtap/2011-q1/threads.html#00082

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.