[4/8] gdb/s390: Fill gen_return_address hook.

  On 03/11/2016 07:33 PM, Eli Zaretskii wrote:
>> 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.

I see what you mean.  I reverted part of the change, and made
the note say the simpler "location" instead now.

> Anyway, if you are happier with your proposal, I won't object.

Below's what I pushed.

Thanks!

From 45fa2529db961adff41c52c3a560808cb135beb2 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 15 Mar 2016 11:08:52 +0000
Subject: [PATCH] Document possible unreliability of '$_ret'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

gdb/doc/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>
	    Andreas Arnez  <arnez@linux.vnet.ibm.com>
	    Marcin Kościelnicki  <koriakin@0x04.net>

	* gdb.texinfo (Tracepoint Actions): Document possible
	unreliability of '$_ret'.
---
 gdb/doc/ChangeLog   | 7 +++++++
 gdb/doc/gdb.texinfo | 7 +++++++
 2 files changed, 14 insertions(+)
  

On Tue, Mar 15 2016, Pedro Alves wrote:

> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index bf7df35..5f88335 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -12878,6 +12878,13 @@ Collect all local variables.
>  Collect the return address.  This is helpful if you want to see more
>  of a backtrace.
>
> +@emph{Note:} The return address location can not always be reliability
                                                              ^^^^^^^^^^^
Should be "reliably" ;-)

> +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).
> +
>  @item $_probe_argc
>  Collects the number of arguments from the static probe at which the
>  tracepoint is located.

--
Andreas