From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85397 invoked by alias); 11 Mar 2016 17:02:25 -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 85379 invoked by uid 89); 11 Mar 2016 17:02:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Collect, Hx-languages-length:1872, our, reliability X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 11 Mar 2016 17:02:23 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 9A7F9486AA; Fri, 11 Mar 2016 17:02:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2BH2Jt6025353; Fri, 11 Mar 2016 12:02:20 -0500 Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook. To: Andreas Arnez References: <1453637529-26972-5-git-send-email-koriakin@0x04.net> <1454853751-18455-1-git-send-email-koriakin@0x04.net> <56E2AD82.3060101@0x04.net> <56E2B95F.7050701@0x04.net> <56E2E7C8.7050901@redhat.com> Cc: Eli Zaretskii , =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <56E2FA1B.7050808@redhat.com> Date: Fri, 11 Mar 2016 17:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00192.txt.bz2 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