This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 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(+)

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 3d49085..0606d9d 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,10 @@
+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'.
+
 2016-03-11  Andrew Burgess  <andrew.burgess@embecosm.com>
 
 	* gdb.texinfo (Symbols): Document new 'maint info line-table'
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
+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.
-- 
2.5.0



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]