From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87705 invoked by alias); 26 Feb 2015 15:15:34 -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 87613 invoked by uid 48); 26 Feb 2015 15:15:30 -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: Thu, 26 Feb 2015 16:25: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-02/txt/msg02938.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #30 from boger at us dot ibm.com --- I don't think it is a good idea to add code in multiple places to fix up the pc values after calling runtime.Callers. That seems prone to error and confusing for future updates to the code. >>From what I can tell, the problem originates with the use of backtrace_full from the libgo code to find the pc stack values for some platforms. I think if the pc was never decremented in the backtrace code then I think the values are right. However I understand you can't just change that behavior due to other existing users of this code that might expect it to continue working as before. Here are some options: - Add a new function to libbacktrace for this situation where the pc is never decremented. - Add a flag to one of the backtrace structures to indicate you don't want the pc decremented in libbacktrace and then use that flag in libbacktrace to control whether the pc is decremented. - Add a wrapper function to the libgo code to call backtrace_full and then adjust the pc value based on the GOARCH value, understanding what backtrace_full might have done and what the GO code expects. Then there should be no direct calls to backtrace_full in libgo, but only calls to this wrapper function. Once the stack pc values are generated as expected then runtime.Callers has the correct values according to what its callers would expect, how it is documented, and matches gc behavior. I think the pc mapping for inlined functions is a separate issue. Inlining happens in gccgo and not gc and happens on all gcc compilers so the mapping of pc values to line numbers for inlined code is not an issue specific to gccgo and that is not the issue in this testcase. Maybe it just needs to be documented so users understand that can happen or maybe inlining should be disabled by default for gccgo and then if users enable it they understand what could happen.