From patchwork Fri Jan 23 12:53:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Metzger, Markus T" X-Patchwork-Id: 4776 Received: (qmail 10551 invoked by alias); 23 Jan 2015 12:53:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 10381 invoked by uid 89); 23 Jan 2015 12:53:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL, BAYES_00, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga14.intel.com Received: from mga14.intel.com (HELO mga14.intel.com) (192.55.52.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Jan 2015 12:53:07 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 23 Jan 2015 04:47:15 -0800 X-ExtLoop1: 1 Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga001.fm.intel.com with ESMTP; 23 Jan 2015 04:53:05 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.229]) by IRSMSX153.ger.corp.intel.com ([169.254.9.2]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 12:53:02 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "palves@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: x86_64-m32 internal error for multi-thread-step.exp [Re: [PATCH v10 06/28] btrace: change branch trace data structure] Date: Fri, 23 Jan 2015 12:53:02 +0000 Message-ID: References: <1389686678-9039-1-git-send-email-markus.t.metzger@intel.com> <1389686678-9039-7-git-send-email-markus.t.metzger@intel.com> <20150108204943.GA4851@host2.jankratochvil.net> <20150122163740.GA11113@host2.jankratochvil.net> In-Reply-To: MIME-Version: 1.0 X-IsSubscribed: yes > -----Original Message----- > From: Metzger, Markus T > Sent: Friday, January 23, 2015 8:46 AM > There also seem to be some issues in reverse/replay stepping. The > reverse-next command keeps going when it reached the previous > source line; same for replay next. I need to investigate why this is. The 32-bit _dl_runtime_resolve returns to the resolved function. The 64-bit _dl_runtime_resolve jumps to the resolved function. The return causes btrace to search for the function in the current stack back trace. Since it doesn't find it, it assumes that the return goes to some outer function that has not been recorded. When we continue processing the trace, we build a new stack back trace with the same function names but different frame id's. They will look the same when using the bt command but stepping won't be able to detect when stepping into a subroutine. My current thinking is that I'd add a special case for this (see below). I can't think of a general case where you would use a return instruction to transfer control to a function that didn't call you. If you know of more such cases, please let me know. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 diff --git a/gdb/btrace.c b/gdb/btrace.c index fd543ef..db31788 100644 --- a/gdb/btrace.c +++ b/gdb/btrace.c @@ -524,7 +524,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. */