[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[boger at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999

--- Comment #42 from boger at us dot ibm.com ---



(In reply to Ian Lance Taylor from comment #41)
> I really don't want libbacktrace to be processor-dependent.  That makes all
> uses of it more complex for no significant gain.  Maybe we should change
> libbacktrace, but definitely not by making it processor-dependent.

I'm sorry but I have to disagree.  In my opinion what libbacktrace does now for
Power and s390/s390x is wrong.  It does not return valid PC values for those
platforms.  Everyone who calls it has to know that they must look through the
list of PC values and change them back.  In addition, libbacktrace has already
looked up the line number information with those invalid PCs.  So essentially
libbacktrace is returning invalid PCs and usually incorrect line numbers which
the caller has to know about and fix up and that seems significant to me.

Maybe the PCs should never be decremented for any platform?

> 
> I would prefer that changes to files like runtime/pprof/pprof.go and
> log/log.go go through the master repo first.  If gccgo's runtime.Callers
> acts the same as gc's runtime.Callers, then there shouldn't be any
> gccgo-specific need to change those files.

Yes I agree that is the way it should be done.  I mainly wanted to show all the
changes in one place for review and didn't think through the process for
getting that code in place.

> 
> Can somebody please try just editing the function callback in
> runtime/go-callers.c to add one to pc when storing it in loc->pc?  I'd like
> to understand why that simple change doesn't work before trying something
> more complex.

Yes I've already tried that.  But I ran into the issues I described in my first
comment above, especially seeing that all the stack information from
runtime_callers had incorrect line information and it is not obvious to the
caller that they should fix that information before using it.  In addition,
there is evidence that looking up the line number information is not cheap, so
doing it in libbacktrace and then having to look it up again if it is needed
seems like a waste especially in those cases when the line number information
is not even used.