From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21436 invoked by alias); 26 Feb 2015 16:11:49 -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 21364 invoked by uid 48); 26 Feb 2015 16:11:41 -0000 From: "ian at airs dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler Date: Thu, 26 Feb 2015 17:08: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: ian at airs dot 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/msg02945.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #32 from Ian Lance Taylor --- > 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. Right, which is why I never suggested that. I suggested changing runtime.Callers itself to adjust the values that it gets from libbacktrace. > - 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. Yes, that is exactly what I have been trying to say, but we don't need to introduce a new function. We already only call backtrace_full from a single place in libgo: runtime_callers (which, to be clear, is not the same as runtime.Callers). > 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. To be clear, libbacktrace can handle inlined functions just fine, and libgo does the right thing for things like the stack traces dumped when a program crashes. It also does the right thing when handling the skip parameter to runtime.Caller and runtime.Callers. The problem arises when converting the libbacktrace values into the single PC value expected by Go functions like runtime.Callers. I am not going to disable inlining by default for gccgo. That would be a performance killer.