public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "boger at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
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	[thread overview]
Message-ID: <bug-64999-4-1CV9WlsWyg@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-64999-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2015-02-26 15:15 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 12:13 [Bug go/64999] New: " vogt at linux dot vnet.ibm.com
2015-02-10 15:21 ` [Bug go/64999] " vogt at linux dot vnet.ibm.com
2015-02-10 15:23 ` ian at airs dot com
2015-02-10 15:25 ` ian at airs dot com
2015-02-10 15:36 ` vogt at linux dot vnet.ibm.com
2015-02-10 15:55 ` vogt at linux dot vnet.ibm.com
2015-02-10 17:20 ` ian at airs dot com
2015-02-11  7:15 ` vogt at linux dot vnet.ibm.com
2015-02-11  7:38 ` vogt at linux dot vnet.ibm.com
2015-02-11 17:45 ` ian at airs dot com
2015-02-12  7:02 ` vogt at linux dot vnet.ibm.com
2015-02-12 16:45 ` ian at airs dot com
2015-02-12 17:24 ` ian at airs dot com
2015-02-16 10:59 ` vogt at linux dot vnet.ibm.com
2015-02-16 11:49 ` vogt at linux dot vnet.ibm.com
2015-02-16 11:50 ` vogt at linux dot vnet.ibm.com
2015-02-16 14:08 ` ian at airs dot com
2015-02-17 11:13 ` vogt at linux dot vnet.ibm.com
2015-02-17 12:07 ` vogt at linux dot vnet.ibm.com
2015-02-17 14:24 ` ian at airs dot com
2015-02-18  9:21 ` vogt at linux dot vnet.ibm.com
2015-02-18 12:28 ` ian at airs dot com
2015-02-18 13:13 ` vogt at linux dot vnet.ibm.com
2015-02-18 18:52 ` ian at airs dot com
2015-02-24 14:07 ` boger at us dot ibm.com
2015-02-24 18:51 ` ian at airs dot com
2015-02-24 22:25 ` boger at us dot ibm.com
2015-02-25  0:17 ` ian at airs dot com
2015-02-25  0:55 ` boger at us dot ibm.com
2015-02-26  9:55 ` vogt at linux dot vnet.ibm.com
2015-02-26 16:25 ` boger at us dot ibm.com [this message]
2015-02-26 16:56 ` ian at airs dot com
2015-02-26 17:08 ` ian at airs dot com
2015-02-26 17:13 ` boger at us dot ibm.com
2015-02-26 18:25 ` ian at airs dot com
2015-03-06 17:24 ` ian at airs dot com
2015-03-06 20:08 ` boger at us dot ibm.com
2015-03-06 21:08 ` ian at airs dot com
2015-03-09 20:56 ` boger at us dot ibm.com
2015-03-09 22:02 ` ian at airs dot com
2015-03-10 12:28 ` boger at us dot ibm.com
2015-03-10 14:21 ` ian at airs dot com
2015-03-10 14:44 ` boger at us dot ibm.com
2015-03-10 16:17 ` ian at airs dot com
2015-03-10 17:49 ` boger at us dot ibm.com
2015-03-10 18:28 ` ian at airs dot com
2015-03-10 20:18 ` boger at us dot ibm.com
2015-03-10 20:45 ` ian at airs dot com
2015-03-12 14:13 ` boger at us dot ibm.com
2015-03-12 15:30 ` ian at airs dot com
2015-04-17 12:47 ` boger at us dot ibm.com
2015-04-17 13:04 ` boger at us dot ibm.com
2015-04-17 19:30 ` ian at gcc dot gnu.org
2015-04-17 19:30 ` ian at gcc dot gnu.org
2015-04-17 21:32 ` ian at airs dot com
2015-04-21  8:28 ` vogt at linux dot vnet.ibm.com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-64999-4-1CV9WlsWyg@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).