public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler Date: Tue, 10 Mar 2015 20:45:00 -0000 [thread overview] Message-ID: <bug-64999-4-t6B52KTkXh@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 #49 from Ian Lance Taylor <ian at airs dot com> --- libbacktrace returns the line number that you actually care about: the line number of the call instruction. There is no question that that is correct. You say that it is a problem if the PC does not match the line number, but to me that sounds like a conceptual problem. What is the actual problem? The pprof.go code expects to get the PC after the call instruction, and tries to turn it into the PC of the call instruction. I think we can all agree that pprof.go should in fact see the PC after the call instruction. The simple way to do that is for callback in libgo/runtime/go-callers.c to increment pc before storing it in loc->pc. Apparently there is some problem with that but I do not know what that problem is. The additional argument I mentioned would be for the function types backtrace_fulL_callback and backtrace_simple_callback defined in libbacktrace/backtrace.h. The additional argument would be, essentially, the value of ip_before_insn in libbacktrace/backtrace.c and libbacktrace/simple.c. The argument would tell you whether the PC follows a call instruction, or whether it is the correct PC for a signal frame instruction.
next prev parent reply other threads:[~2015-03-10 20:45 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 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 [this message] 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-t6B52KTkXh@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: linkBe 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).