Message ID | m3y49px8tf.fsf@oc1027705133.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 24832 invoked by alias); 11 Mar 2016 16:45:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 17258 invoked by uid 89); 11 Mar 2016 16:45:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Collect, H*o:Research, our, reliability X-HELO: e06smtp10.uk.ibm.com Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 11 Mar 2016 16:45:24 +0000 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Fri, 11 Mar 2016 16:45:21 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 11 Mar 2016 16:45:19 -0000 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: arnez@linux.vnet.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2D7051B0806B for <gdb-patches@sourceware.org>; Fri, 11 Mar 2016 16:45:45 +0000 (GMT) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2BGjIAT55705778 for <gdb-patches@sourceware.org>; Fri, 11 Mar 2016 16:45:18 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2BGjHCI015943 for <gdb-patches@sourceware.org>; Fri, 11 Mar 2016 09:45:17 -0700 Received: from oc1027705133.ibm.com (dyn-9-152-212-180.boeblingen.de.ibm.com [9.152.212.180]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2BGjGva015916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2016 09:45:17 -0700 From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: Pedro Alves <palves@redhat.com> Cc: Eli Zaretskii <eliz@gnu.org> Cc: Marcin =?utf-8?Q?Ko=C5=9Bcielnicki?= <koriakin@0x04.net>, gdb-patches@sourceware.org Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook. References: <1453637529-26972-5-git-send-email-koriakin@0x04.net> <1454853751-18455-1-git-send-email-koriakin@0x04.net> <m3bn6lz2fu.fsf@oc1027705133.ibm.com> <56E2AD82.3060101@0x04.net> <m37fh9yzqn.fsf@oc1027705133.ibm.com> <56E2B95F.7050701@0x04.net> <m337rxyqt9.fsf@oc1027705133.ibm.com> <56E2E7C8.7050901@redhat.com> Date: Fri, 11 Mar 2016 17:45:16 +0100 In-Reply-To: <56E2E7C8.7050901@redhat.com> (Pedro Alves's message of "Fri, 11 Mar 2016 15:44:08 +0000") Message-ID: <m3y49px8tf.fsf@oc1027705133.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16031116-0041-0000-0000-000007C272B0 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
March 11, 2016, 4:45 p.m. UTC
On Fri, Mar 11 2016, Pedro Alves wrote: > On 03/11/2016 03:31 PM, Andreas Arnez wrote: >> So I'm OK with the patch. Please add a small comment stating that this >> is a best-can-do approach that usually works near function entry and may >> yield wrong results otherwise. > > I think that should be put in the manual, even. Users will also trip on > this, not just our tests. Right, I thought about this as well. How about this? -- >8 -- Subject: [PATCH] Document possible unreliability of `$_ret'
Comments
On 03/11/2016 04:45 PM, Andreas Arnez wrote: > On Fri, Mar 11 2016, Pedro Alves wrote: > >> On 03/11/2016 03:31 PM, Andreas Arnez wrote: >>> So I'm OK with the patch. Please add a small comment stating that this >>> is a best-can-do approach that usually works near function entry and may >>> yield wrong results otherwise. >> >> I think that should be put in the manual, even. Users will also trip on >> this, not just our tests. > > Right, I thought about this as well. How about this? > > -- >8 -- > Subject: [PATCH] Document possible unreliability of `$_ret' > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 4ec0ec1..a14fe19 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -12863,7 +12863,9 @@ Collect all local variables. > > @item $_ret > Collect the return address. This is helpful if you want to see more > -of a backtrace. > +of a backtrace. Note that the return address can not always be > +determined reliably, and a wrong address may be collected instead. > +The reliability is usually higher for tracepoints at function entry. Hmm, this reads a bit as if the backtrace will be incorrect/bogus later on, which is not true. How about a merge of your suggestion with Marcin's previous reply, and some extras on top: @item $_ret Collect the set of memory addresses and/or registers necessary to compute the frame's return address. This is helpful if you want to see more of a backtrace. @emph{Note:} The necessary set can not always be reliability determined up front, and the wrong address / registers may end up collected instead. The reliability is usually higher for tracepoints at function entry. When this happens, backtracing will stop because the return address is found unavailable (unless another collect rule happened to match it). Thanks, Pedro Alves
> From: Andreas Arnez <arnez@linux.vnet.ibm.com> > Cc: Eli Zaretskii <eliz@gnu.org> > Cc: Marcin Kościelnicki <koriakin@0x04.net>, gdb-patches@sourceware.org > Date: Fri, 11 Mar 2016 17:45:16 +0100 > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 4ec0ec1..a14fe19 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -12863,7 +12863,9 @@ Collect all local variables. > > @item $_ret > Collect the return address. This is helpful if you want to see more > -of a backtrace. > +of a backtrace. Note that the return address can not always be > +determined reliably, and a wrong address may be collected instead. > +The reliability is usually higher for tracepoints at function entry. LGTM, thanks.
> Cc: Eli Zaretskii <eliz@gnu.org>, > Marcin Kościelnicki > <koriakin@0x04.net>, > gdb-patches@sourceware.org > From: Pedro Alves <palves@redhat.com> > Date: Fri, 11 Mar 2016 17:02:19 +0000 > > > @item $_ret > > Collect the return address. This is helpful if you want to see more > > -of a backtrace. > > +of a backtrace. Note that the return address can not always be > > +determined reliably, and a wrong address may be collected instead. > > +The reliability is usually higher for tracepoints at function entry. > > Hmm, this reads a bit as if the backtrace will be incorrect/bogus > later on, which is not true. > > How about a merge of your suggestion with Marcin's previous reply, > and some extras on top: > > @item $_ret > Collect the set of memory addresses and/or registers necessary to compute > the frame's return address. This is helpful if you want to see > more of a backtrace. > > @emph{Note:} The necessary set can not always be reliability determined up > front, and the wrong address / registers may end up collected instead. > The reliability is usually higher for tracepoints at function entry. > When this happens, backtracing will stop because the return address > is found unavailable (unless another collect rule happened to match it). Maybe it's me, but I don't see the significant difference between these two versions. (And there's a typo in the second one: "reliability" should be "reliably".) Thanks.
On 03/11/2016 06:16 PM, Eli Zaretskii wrote: >> Cc: Eli Zaretskii <eliz@gnu.org>, >> Marcin Kościelnicki >> <koriakin@0x04.net>, >> gdb-patches@sourceware.org >> From: Pedro Alves <palves@redhat.com> >> Date: Fri, 11 Mar 2016 17:02:19 +0000 >> >>> @item $_ret >>> Collect the return address. This is helpful if you want to see more >>> -of a backtrace. >>> +of a backtrace. Note that the return address can not always be >>> +determined reliably, and a wrong address may be collected instead. >>> +The reliability is usually higher for tracepoints at function entry. >> >> Hmm, this reads a bit as if the backtrace will be incorrect/bogus >> later on, which is not true. >> >> How about a merge of your suggestion with Marcin's previous reply, >> and some extras on top: >> >> @item $_ret >> Collect the set of memory addresses and/or registers necessary to compute >> the frame's return address. This is helpful if you want to see >> more of a backtrace. >> >> @emph{Note:} The necessary set can not always be reliability determined up >> front, and the wrong address / registers may end up collected instead. >> The reliability is usually higher for tracepoints at function entry. >> When this happens, backtracing will stop because the return address >> is found unavailable (unless another collect rule happened to match it). > > Maybe it's me, but I don't see the significant difference between > these two versions. I think the original version can be misinterpreted as if the backtrace will show the wrong caller when the wrong address is collected. This version clarifies that it won't. > (And there's a typo in the second one: > "reliability" should be "reliably".) Whoops. Thanks, Pedro Alves
> Cc: arnez@linux.vnet.ibm.com, koriakin@0x04.net, gdb-patches@sourceware.org > From: Pedro Alves <palves@redhat.com> > Date: Fri, 11 Mar 2016 18:37:22 +0000 > > On 03/11/2016 06:16 PM, Eli Zaretskii wrote: > >> Cc: Eli Zaretskii <eliz@gnu.org>, > >> Marcin Kościelnicki > >> <koriakin@0x04.net>, > >> gdb-patches@sourceware.org > >> From: Pedro Alves <palves@redhat.com> > >> Date: Fri, 11 Mar 2016 17:02:19 +0000 > >> > >>> @item $_ret > >>> Collect the return address. This is helpful if you want to see more > >>> -of a backtrace. > >>> +of a backtrace. Note that the return address can not always be > >>> +determined reliably, and a wrong address may be collected instead. > >>> +The reliability is usually higher for tracepoints at function entry. > >> > >> Hmm, this reads a bit as if the backtrace will be incorrect/bogus > >> later on, which is not true. > >> > >> How about a merge of your suggestion with Marcin's previous reply, > >> and some extras on top: > >> > >> @item $_ret > >> Collect the set of memory addresses and/or registers necessary to compute > >> the frame's return address. This is helpful if you want to see > >> more of a backtrace. > >> > >> @emph{Note:} The necessary set can not always be reliability determined up > >> front, and the wrong address / registers may end up collected instead. > >> The reliability is usually higher for tracepoints at function entry. > >> When this happens, backtracing will stop because the return address > >> is found unavailable (unless another collect rule happened to match it). > > > > Maybe it's me, but I don't see the significant difference between > > these two versions. > > I think the original version can be misinterpreted as if the > backtrace will show the wrong caller when the wrong address > is collected. This version clarifies that it won't. My reading is the other way around: the original version only talks about the return address, while the modified one talks about a set of addresses. Anyway, if you are happier with your proposal, I won't object.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 4ec0ec1..a14fe19 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -12863,7 +12863,9 @@ Collect all local variables. @item $_ret Collect the return address. This is helpful if you want to see more -of a backtrace. +of a backtrace. Note that the return address can not always be +determined reliably, and a wrong address may be collected instead. +The reliability is usually higher for tracepoints at function entry. @item $_probe_argc Collects the number of arguments from the static probe at which the