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.
