From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121275 invoked by alias); 24 Feb 2015 21:29:57 -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 121218 invoked by uid 48); 24 Feb 2015 21:29:54 -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, 24 Feb 2015 22: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/msg02710.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #26 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #25) > To which code in libgcc are you referring? I don't see it. > Here is the code I was referring to, but I was wrong when I thought it fixed the problem. Even though the testcase passed on further inspection I see that the pc values are still wrong. ip a.k.a. pc unwind-c.c: #ifdef HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); #else ip = _Unwind_GetIP (context); #endif if (! ip_before_insn) --ip; > Our goal has to be for runtime.Callers to return the same sort of values in > gccgo as it does in gc. That means that your change to > go/runtime/pprof/pprof.go looks wrong to me. It suggests that the ppc64 > values are different from those of other architectures. What's the > justification for that? Sorry I was only experimenting with a solution for Power, just to understand what could be changed to make it work so it was not meant to be a solution for other platforms. I could see that the pc was being decremented wrong for Power so once I fixed that it didn't make sense to decrement it again in pprof.go. That was my thinking. After rereading all you've wrote I think we are coming to same result (somewhat). If I read the documentation for runtime.Callers, it says that the pc values are the return program counters, but in gccgo it is program counter for the call instruction, so runtime.Callers does need to be changed. But in one place you are just incrementing the pc, so won't that be wrong for the cases where libbacktrace didn't decrement it?