Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Marcin Kościelnicki" <koriakin@0x04.net>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org,
	Andreas Arnez <arnez@linux.vnet.ibm.com>,
	Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH 4/8] gdb/s390: Fill gen_return_address hook.
Date: Fri, 11 Mar 2016 17:43:00 -0000	[thread overview]
Message-ID: <56E303A6.6090303@0x04.net> (raw)
In-Reply-To: <56E30183.40204@redhat.com>

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.


  reply	other threads:[~2016-03-11 17:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8ce93c6f-5822-4e27-9e59-c6cbe158424d@email.android.com>
2016-03-11 17:34 ` Pedro Alves
2016-03-11 17:43   ` Marcin Kościelnicki [this message]
2016-01-24 12:12 [PATCH 0/8] gdb/s390: Add regular and fast tracepoint support Marcin Kościelnicki
2016-01-24 12:12 ` [PATCH 4/8] gdb/s390: Fill gen_return_address hook Marcin Kościelnicki
2016-02-07 14:02   ` Marcin Kościelnicki
2016-02-25 19:23     ` Marcin Kościelnicki
2016-03-04 10:42       ` Marcin Kościelnicki
2016-03-11 11:20     ` Andreas Arnez
2016-03-11 11:35       ` Marcin Kościelnicki
2016-03-11 12:18         ` Andreas Arnez
2016-03-11 12:26           ` Marcin Kościelnicki
2016-03-11 15:31             ` Andreas Arnez
2016-03-11 15:44               ` Pedro Alves
2016-03-11 16:45                 ` Andreas Arnez
2016-03-11 17:02                   ` Pedro Alves
2016-03-11 18:17                     ` Eli Zaretskii
2016-03-11 18:37                       ` Pedro Alves
2016-03-11 19:34                         ` Eli Zaretskii
2016-03-15 11:11                           ` Pedro Alves
2016-03-15 11:23                             ` Andreas Arnez
2016-03-15 11:30                               ` Pedro Alves
2016-03-11 18:07                   ` Eli Zaretskii
2016-03-13  9:53               ` Marcin Kościelnicki
2016-03-14 10:07                 ` Andreas Arnez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E303A6.6090303@0x04.net \
    --to=koriakin@0x04.net \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox