From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51139 invoked by alias); 10 Mar 2015 17:49:23 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 50800 invoked by uid 48); 10 Mar 2015 17:49:19 -0000 From: "boger at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler Date: Tue, 10 Mar 2015 17:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: boger at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg01150.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #46 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #45) > If we change the PC returned by backtrace_full, and then use that changed PC > to look up file/line information, we might get different results. That > seems clear. My next question is: when does this matter? > > There are two ways that we use the result of runtime_callers: either we use > the file/line information, or we use the PC. If we use the file/line > information, all is well, and there is nothing to discuss. If we use the > PC, as in runtime.Callers, then it's true that if we pass that PC back to > libbacktrace we may get different file/line information. But, so what? > We've already lost the original file/line information anyhow. > > The idea is that the changed PC will be the same as the PC returned by the > gc library. Therefore, we should get approximately the same file/line > information as the gc library gets. That is why runtime/pprof/pprof.go in > the gc library backs up the PC to the call instruction: because it knows > that it has the PC after the call instruction. Let me just respond to this last paragraph for now. If the pc values in gc are always the instruction following the call (or the excepting instruction), and runtime_callers expects it to be that way, and we want gc and gccgo to return the same results, then I don't understand why backtrace_full and backtrace_simple should ever decrement the pc for any platform. There is a brief mention of this in comment 9 -- that we can make use the fact that the pc had been decremented by inspecting it and making use of the fact that is an abnormal pc value; however I don't see anywhere in the libgo code where it does this, and besides, for some platforms after the pc is decremented it is still a normal looking pc so there is no way to know if it had been decremented. Getting the right pc and the right instruction seems more important than preserving some information that is currently not being used and can't be used on all platforms. That means, if the decrement was removed completely from backtrace_full and backtrace_simple then the pc values would be correct for each platform and the line numbers would be determined based on the correct pc. And then we would still need the BackupPC function for those cases where the call instruction was needed as is done in pprof.go and some extra stuff for s390 and s390x for their various call instructions to get the right number of bytes to back up.