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

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

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

--- Comment #56 from boger at us dot ibm.com ---
Here is a bit more detail.  Now that I think I understand all the
considerations, I'm proposing this simple fix for gcc 5.  Maybe longer term a
more thorough solution could be done but not sure it is worth changing multiple
functions to add an additional argument and changing external header files in
gcc 5.

The problems to be fixed are:
- the pc in the call stack returned by runtime_callers is wrong for some
platforms, such as Power and Z and possibly others
- the pc adjustment and line number that is looked up in go/runtime/pprof.go
sometimes provides the wrong line number if based on the bad pc

The proposed fix is to increment the pc in the callback routine that is passed
to backtrace_full when trying to find the runtime_callers all the time.  During
the unwind the pc was decremented for the normal call case.  If it was a
signal, the pc would not have been decremented so it is being incremented
unnecessarily for that situation but I think that is OK since the line number
will be right and the pc will still refer to the signalling instruction.

As far as the change to the pprof code, at least in gccgo for Power and Z the
pc and the line number should be correct so no adjustment is even needed, but
my understanding from previous posts is that in the gc compiled case an
adjustment is needed and this code is common for gc and gccgo?  With the pprof
code that is there now, the pprof code is OK for Power, i.e., the line number
in the pprof testcase matches the expected line number.  For Z, I think that
the amount to decrement should be the minimum size for a call instruction (not
sure what that value is) and then the tracepc value would refer to the previous
instruction.

Note that the pprof testcase does not yet work even with this fix because there
is a new problem that fails on all platforms with gccgo described here: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683.