https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #48 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #47) > We have to separate backtrace_full and backtrace_simple, which are part of > the libbacktrace library, from functions like runtime_callers which are part > of libgo. The libbacktrace library is used by several different projects. > It is not part of libgo. > > It may be correct that libbacktrace should never decrement pc. But the > argument for that can't be the behaviour of the gc library. > The backtraces I'm familiar with are those where the pc values represent the instruction after the call. Regardless of what the gc library does I don't see why you'd want to decrement the pcs in backtrace_full. Actually to me it seems like decrementing it would be wrong for all platforms (based on what is done in pprof.go -- doesn't that mean in some cases it would get decremented twice?) but I just haven't had time to investigate that further. > The bit in comment #9 about not decrementing the pc for a signal frame is > specific to libbacktrace. You can see that in unwind in > libbacktrace/backtrace.c and in simple_unwind in libbacktrace/simple.c. > > Perhaps we need to change libbacktrace so that backtrace_full_callback and > backtrace_simple_callback take an additional parameter, which is whether the > PC is in a signal frame. From libgo's perspective, though, that would be > exactly the same as simply always adding to pc in callback in go-callers.c. > You said that did not work, and I'm still trying to understand why. I'm not exactly sure what you are describing -- which functions would have an additional argument and what would you do with that argument. Here is the problem with incrementing the pc in the callback. In unwind the pc is decremented, and the line number is looked up for that pc and saved away. Then callback is called, and the pc is incremented, but now the line number that was saved away is stale. That means when on return to runtime_callers, the pcs are all correct but some line numbers might not be right for those pcs. I tried adding code to look up the line number again in the callback after the pc was modified but that caused the program to hang.
