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

Marcin Kościelnicki koriakin@0x04.net
Fri Mar 11 17:43:00 GMT 2016


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 <palves@redhat.com> 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.



More information about the Gdb-patches mailing list