https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #50 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #49) > libbacktrace returns the line number that you actually care about: the line > number of the call instruction. There is no question that that is correct. > > You say that it is a problem if the PC does not match the line number, but > to me that sounds like a conceptual problem. What is the actual problem? > > The pprof.go code expects to get the PC after the call instruction, and > tries to turn it into the PC of the call instruction. I think we can all > agree that pprof.go should in fact see the PC after the call instruction. > The simple way to do that is for callback in libgo/runtime/go-callers.c to > increment pc before storing it in loc->pc. Apparently there is some problem > with that but I do not know what that problem is. > > The additional argument I mentioned would be for the function types > backtrace_fulL_callback and backtrace_simple_callback defined in > libbacktrace/backtrace.h. The additional argument would be, essentially, > the value of ip_before_insn in libbacktrace/backtrace.c and > libbacktrace/simple.c. The argument would tell you whether the PC follows a > call instruction, or whether it is the correct PC for a signal frame > instruction OK. I didn't realize that backtrace_full is expected to return an array of Location structures which contain the PC for the instruction following the call but the line number for the call. When I saw there was a single structure containing a PC and lineno, I assumed that it was intended to hold information for a single location, i.e., a PC and the lineno that corresponded to it. I will go back and try this again as you suggested. I had tried several variations and hit different errors and when I saw how the line number and PC were out of sync that steered me down the wrong path. Now that I understand what it really should be I think it should probably work.
