From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54807 invoked by alias); 7 Feb 2017 07:27:34 -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 54782 invoked by uid 89); 7 Feb 2017 07:27:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:826ae22, U*patches, H*MI:sk:826ae22, H*f:sk:826ae22 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; Tue, 07 Feb 2017 07:27:22 +0000 Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP; 06 Feb 2017 23:27:20 -0800 X-ExtLoop1: 1 Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga004.jf.intel.com with ESMTP; 06 Feb 2017 23:27:20 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Feb 2017 07:27:19 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.142]) by IRSMSX156.ger.corp.intel.com ([169.254.3.104]) with mapi id 14.03.0248.002; Tue, 7 Feb 2017 07:27:19 +0000 From: "Metzger, Markus T" To: Luis Machado , "gdb-patches@sourceware.org" Subject: RE: [PATCH] btrace: preserve call stack on function switch Date: Tue, 07 Feb 2017 07:27:00 -0000 Message-ID: References: <1485940343-29405-1-git-send-email-markus.t.metzger@intel.com> <826ae22f-eec3-2f4b-756b-a8ecee8defbc@codesourcery.com> In-Reply-To: <826ae22f-eec3-2f4b-756b-a8ecee8defbc@codesourcery.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00141.txt.bz2 Hello Luis, Thanks for your review. > From what i understood, this adds an heuristic where previously there > was none? We just declared defeat before the patch? We previously preserved the stack-level but not the caller information. Th= is left the parts of the trace before and after the switch disconnected at hig= her levels. Regards, Markus. > -----Original Message----- > From: Luis Machado [mailto:lgustavo@codesourcery.com] > Sent: Tuesday, February 7, 2017 12:56 AM > To: Metzger, Markus T ; gdb- > patches@sourceware.org > Subject: Re: [PATCH] btrace: preserve call stack on function switch >=20 > On 02/01/2017 03:12 AM, Markus Metzger wrote: > > On 64-bit FC25, the _dl_runtime_resolve function uses a conditional bra= nch to > > 'call' a particular variant optimized for that system: > > > > (gdb) disas _dl_runtime_resolve_avx_opt > > Dump of assembler code for function _dl_runtime_resolve_avx_opt: > > 0x00007ffff7deeb60 <+0>: push %rax > > 0x00007ffff7deeb61 <+1>: push %rcx > > 0x00007ffff7deeb62 <+2>: push %rdx > > 0x00007ffff7deeb63 <+3>: mov $0x1,%ecx > > 0x00007ffff7deeb68 <+8>: xgetbv > > 0x00007ffff7deeb6b <+11>: mov %eax,%r11d > > 0x00007ffff7deeb6e <+14>: pop %rdx > > 0x00007ffff7deeb6f <+15>: pop %rcx > > 0x00007ffff7deeb70 <+16>: pop %rax > > 0x00007ffff7deeb71 <+17>: and $0x4,%r11d > > 0x00007ffff7deeb75 <+21>: bnd je 0x7ffff7def4a0 > <_dl_runtime_resolve_sse_vex> > > End of assembler dump. > > > > When computing the function-level trace, btrace treats this as a switch= from > > _dl_runtime_resolve_avx_opt to _dl_runtime_resolve_sse_vex. We know > that we > > switched functions but we can't really say in which caller/callee relat= ionship > > those two functions are. > > > > In addition to preserving the indentaion level, also preserve the caller > > information. This is a heuristic since we don't really know. But at l= east in > > this case, this seems to be the right thing to do. > > > > This fixes a fail in gdb.btrace/rn-dl-bind.exp on 64-bit FC25. > > > > 2017-02-01 Markus Metzger > > > > * btrace.c (ftrace_new_switch): Preserve up link and flags. > > --- > > gdb/btrace.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/gdb/btrace.c b/gdb/btrace.c > > index 6d621e4..ddf6692 100644 > > --- a/gdb/btrace.c > > +++ b/gdb/btrace.c > > @@ -448,9 +448,11 @@ ftrace_new_switch (struct btrace_function *prev, > > { > > struct btrace_function *bfun; > > > > - /* This is an unexplained function switch. The call stack will like= ly > > - be wrong at this point. */ > > + /* This is an unexplained function switch. We can't really be sure = about the > > + call stack, yet the best I can think of right now is to preserve = it. */ > > bfun =3D ftrace_new_function (prev, mfun, fun); > > + bfun->up =3D prev->up; > > + bfun->flags =3D prev->flags; > > > > ftrace_debug (bfun, "new switch"); > > > > >=20 > I don't know much about btrace, but the patch looks reasonable given the > explanation. >=20 > From what i understood, this adds an heuristic where previously there > was none? We just declared defeat before the patch? Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928