On Fri, Apr 17, 2015 at 1:03 PM, <mse...@redhat.com> wrote: > On 04/17/2015 01:29 PM, Ian Lance Taylor wrote: >> >> The libbacktrace library returns a PC that was (usually) decremented >> to be part of the call instruction. The Go code that uses >> runtime.Callers does not expect this, and Go code that adjusts the PC >> value, such as libgo/go/runtime/pprof/pprof.go, can get fooled by it. >> This leads to GCC PRs 64999 and 65180. > > There are a couple of bugs in libsanitizer with symptoms similar to > those noted in 65180: 65749 and the related 65479. I've been looking > into these but don't have a patch yet. What I've found is that using > the decremented PC leads to the wrong line numbers on some targets > (e.g, powerpc) while using the correct PC causes the same problem on > others (such as x86_64) as a result of differences in the DWARF line > programs emitted on these targets.
I don't know what your options are for libsanitizer. For libgo I am somewhat constrained by not wanting to vary too far from the master library. That causes problems because the master library thinks that a single PC value can represent a function/file/line, which is not correct in the presence of inlined functions. If libsanitizer is also using a single PC value, then there isn't much you can do. But if libsanitizer can work with the full function/file/line information returned by backtrace_full, then I think you should always have the correct information even if the precisely correct PC is difficult to know. Ian
