From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49938 invoked by alias); 11 Mar 2016 19:34:28 -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 49915 invoked by uid 89); 11 Mar 2016 19:34:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=happier, Hx-languages-length:2103, HX-Received-From:4830, HX-Received-From:134 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 11 Mar 2016 19:34:17 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeSpA-0007IJ-2q for gdb-patches@sourceware.org; Fri, 11 Mar 2016 14:34:15 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeSp9-0007IF-Vh; Fri, 11 Mar 2016 14:34:12 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3967 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aeSp9-00047y-3h; Fri, 11 Mar 2016 14:34:11 -0500 Date: Fri, 11 Mar 2016 19:34:00 -0000 Message-Id: <83h9gcizcb.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: arnez@linux.vnet.ibm.com, koriakin@0x04.net, gdb-patches@sourceware.org In-reply-to: <56E31062.7020707@redhat.com> (message from Pedro Alves on Fri, 11 Mar 2016 18:37:22 +0000) Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook. Reply-to: Eli Zaretskii 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> <56E2FA1B.7050808@redhat.com> <83shzwj2wt.fsf@gnu.org> <56E31062.7020707@redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00199.txt.bz2 > Cc: arnez@linux.vnet.ibm.com, koriakin@0x04.net, gdb-patches@sourceware.org > From: Pedro Alves > Date: Fri, 11 Mar 2016 18:37:22 +0000 > > On 03/11/2016 06:16 PM, Eli Zaretskii wrote: > >> Cc: Eli Zaretskii , > >> Marcin Kościelnicki > >> , > >> gdb-patches@sourceware.org > >> From: Pedro Alves > >> 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.