[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 #40 from boger at us dot ibm.com ---
Created attachment 34995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34995&action=edit
Proposed fix

Here is my proposed fix to correct the problem on Power, and mostly fix it for
s390/s390x.  Since I don't know the details on the s390/s390x call instructions
that have different sizes, I didn't add the code to fix the problem where the
call instruction might not be 6 bytes.

Description:

- I made a change to avoid doing the decrement in libbacktrace for Power and
s390/s390x.  I think it is better to do it this way than having libbacktrace
decrement it and then on return or through the callback increment it.  If it is
fixed up in the callback or after the return then the line number information
has already been determined in libbacktrace and it could be incorrect.  My
assumption is that no other platform has the issue with the decrement of the PC
since there are no bugzillas for them so the change in libbacktrace is only
needed for Power and s390/s390x.
- I added a new function BackupPC to back up the PC by one instruction by
subtracting the correct instruction size for the platform.  As mentioned above,
some extra work is needed here to handle different call instructions with
different sizes.
- All callers of runtime_callers, runtime.Caller, and runtime.Callers have to
recognize that the PC values being returned represent the instruction following
the call instruction, so if the call instruction is what is needed, the code
will do the back up of the PC and determine the line number based on the new
PC.  I had to make a change to log.go to do this otherwise log_test.go failed. 
I changed the code in pprof.go to call the new function.

With my patch, the line number information is now correct but the mprof
testcase fails due to other differences in the mprof output.  My patch applied
to commit 220481 works and it fails on commit 221230, but have not yet narrowed
it down to the exact commit where it starts to fail.  I am investigating
further, but here is where the output differs:

testing.go:370: The entry did not match:
                (0|1): (0|2097152) \[1: 2097152\] @ 0x[0-9,a-f x]+
                #       0x[0-9,a-f]+   
pprof_test\.allocateTransient2M\+0x[0-9,a-f]+   .*/mprof_test.go:30
                #       0x[0-9,a-f]+   
runtime_pprof_test\.TestMemoryProfiler\+0x[0-9,a-f]+    .*/mprof_test.go:65


0: 0 [1: 32] @ 0x1002815c 0x1002815c 0x10011a48 0x1000b510 0x1000b7b0
0x100c5a00 0x1001fed4
                #       0x1000b510      pprof_test.allocateTransient2M+0x50    
       
/home/boger/gccgo.work/go1.4/150121/bld/powerpc64le-linux/libgo/gotest8260/test/mprof_test.go:30
                #       0x1000b7b0     
runtime_pprof_test.TestMemoryProfiler+0x170    
/home/boger/gccgo.work/go1.4/150121/bld/powerpc64le-linux/libgo/gotest8260/test/mprof_test.go:65

On the first line, the actual output contains [1: 32] but the expected output
is [1: 2097152].

I built the latest gccgo on an x86 with no extra patches and this same failure
occurs there.