From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3213 invoked by alias); 29 Jan 2015 16:29:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3133 invoked by uid 89); 29 Jan 2015 16:29:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jan 2015 16:29:54 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 29 Jan 2015 08:28:25 -0800 X-ExtLoop1: 1 Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga002.fm.intel.com with ESMTP; 29 Jan 2015 08:28:23 -0800 Received: from ulvlx001.iul.intel.com (ulvlx001.iul.intel.com [172.28.207.17]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id t0TGSNpH020058; Thu, 29 Jan 2015 16:28:23 GMT Received: from ulvlx001.iul.intel.com (localhost [127.0.0.1]) by ulvlx001.iul.intel.com with ESMTP id t0TGSN1E010146; Thu, 29 Jan 2015 17:28:23 +0100 Received: (from mmetzger@localhost) by ulvlx001.iul.intel.com with œ id t0TGSNl9010138; Thu, 29 Jan 2015 17:28:23 +0100 From: Markus Metzger To: palves@redhat.com Cc: gdb-patches@sourceware.org, Jan Kratochvil Subject: [PATCH v3 11/15] btrace: work around _dl_runtime_resolve returning to resolved function Date: Thu, 29 Jan 2015 16:33:00 -0000 Message-Id: <1422548899-9789-12-git-send-email-markus.t.metzger@intel.com> In-Reply-To: <1422548899-9789-1-git-send-email-markus.t.metzger@intel.com> References: <1422548899-9789-1-git-send-email-markus.t.metzger@intel.com> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00774.txt.bz2 On some systems, _dl_runtime_resolve returns to the resolved function instead of jumping to it. Since btrace will not find the function in the current stack back trace, it will start a new back trace on the same level. It will look the same to the user via the backtrace command but the frames will have different id's which confuses stepping. This fixes a test fail on 32-bit systems reported by Jan Kratochvil. CC: Jan Kratochvil 2015-01-29 Markus Metzger gdb/ * btrace.c (ftrace_update_function): Treat return as tailcall for "_dl_runtime_resolve". --- gdb/btrace.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/gdb/btrace.c b/gdb/btrace.c index b29e0b2..45e9035 100644 --- a/gdb/btrace.c +++ b/gdb/btrace.c @@ -506,7 +506,24 @@ ftrace_update_function (struct btrace_function *bfun, CORE_ADDR pc) switch (last->iclass) { case BTRACE_INSN_RETURN: - return ftrace_new_return (bfun, mfun, fun); + { + const char *fname; + + /* On some systems, _dl_runtime_resolve returns to the resolved + function instead of jumping to it. From our perspective, + however, this is a tailcall. + If we treated it as return, we wouldn't be able to find the + resolved function in our stack back trace. Hence, we would + lose the current stack back trace and start anew with an empty + back trace. When the resolved function returns, we would then + create a stack back trace with the same function names but + different frame id's. This will confuse stepping. */ + fname = ftrace_print_function_name (bfun); + if (strcmp (fname, "_dl_runtime_resolve") == 0) + return ftrace_new_tailcall (bfun, mfun, fun); + + return ftrace_new_return (bfun, mfun, fun); + } case BTRACE_INSN_CALL: /* Ignore calls to the next instruction. They are used for PIC. */ -- 1.8.3.1