[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

["boger at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999

--- Comment #26 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #25)
> To which code in libgcc are you referring?  I don't see it.
> 

Here is the code I was referring to, but I was wrong when I thought it fixed
the problem.  Even though the testcase passed on further inspection I see that
the pc values are still wrong.

ip a.k.a. pc

unwind-c.c:

#ifdef HAVE_GETIPINFO
  ip = _Unwind_GetIPInfo (context, &ip_before_insn);
#else
  ip = _Unwind_GetIP (context);
#endif
  if (! ip_before_insn)
    --ip;

> Our goal has to be for runtime.Callers to return the same sort of values in
> gccgo as it does in gc.  That means that your change to
> go/runtime/pprof/pprof.go looks wrong to me.  It suggests that the ppc64
> values are different from those of other architectures.  What's the
> justification for that?

Sorry I was only experimenting with a solution for Power, just to understand
what could be changed to make it work so it was not meant to be a solution for
other platforms.  I could see that the pc was being decremented wrong for Power
so once I fixed that it didn't make sense to decrement it again in pprof.go. 
That was my thinking.

After rereading all you've wrote I think we are coming to same result
(somewhat).  If I read the documentation for runtime.Callers, it says that the
pc values are the return program counters, but in gccgo it is program counter
for the call instruction, so runtime.Callers does need to be changed.  But in
one place you are just incrementing the pc, so won't that be wrong for the
cases where libbacktrace didn't decrement it?