From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53528 invoked by alias); 11 Mar 2016 17:43:08 -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 52301 invoked by uid 89); 11 Mar 2016 17:43:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3349, our X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Mar 2016 17:43:06 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id B87953FF1B; Fri, 11 Mar 2016 18:44:02 +0100 (CET) Received: from [192.168.13.108] (unknown [192.168.13.108]) by hogfather.0x04.net (Postfix) with ESMTPSA id 5DA9E5800F9; Fri, 11 Mar 2016 18:43:03 +0100 (CET) Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook. To: Pedro Alves References: <8ce93c6f-5822-4e27-9e59-c6cbe158424d@email.android.com> <56E30183.40204@redhat.com> Cc: gdb-patches@sourceware.org, Andreas Arnez , Eli Zaretskii From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56E303A6.6090303@0x04.net> Date: Fri, 11 Mar 2016 17:43: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: <56E30183.40204@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00195.txt.bz2 On 11/03/16 18:33, Pedro Alves wrote: > On 03/11/2016 05:19 PM, Marcin Kościelnicki wrote: >> >> 11 mar 2016 6:02 PM Pedro Alves napisał(a): >> > >> > 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). >> >> Note that this is arch-dependent: powerpc/s390/aarch64 will work at >> entry (since they dump LR), while x86 has the opposite problem: it uses >> the frame pointer and will never work at entry (or with >> -fomit-frame-pointer for that matter). > > OK. I wouldn't want to go too deep into details here, I think just > pointing in the direction of experimenting with different tracepoint > addresses, if important, may be sufficient. > > @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. > On some architectures the reliability is higher for tracepoints > at function entry, while on others it's the opposite. > When this happens, backtracing will stop because the return address > is found unavailable (unless another collect rule happened to match it). > > WDYT? > > Thanks, > Pedro Alves > Sounds OK to me.