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.
next prev parent 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