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.
