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.


> 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.

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


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