From: Pedro Alves <pedro@palves.net>
To: "Luis Machado" <luis.machado@arm.com>,
"Torbjörn SVENSSON" <torbjorn.svensson@foss.st.com>,
gdb-patches@sourceware.org
Subject: Re: [PATCH v2] gdb/arm: Stop unwinding on error, but do not assert
Date: Thu, 13 Oct 2022 14:41:18 +0100 [thread overview]
Message-ID: <c449141a-4369-a59d-ccda-0ce837a9e78c@palves.net> (raw)
In-Reply-To: <94af9e31-5092-1b6d-8520-d58c13d02631@arm.com>
On 2022-10-13 2:11 p.m., Luis Machado wrote:
> On 10/13/22 12:21, Pedro Alves wrote:
>> On 2022-10-13 10:17 a.m., Torbjörn SVENSSON via Gdb-patches wrote:
>>
>>> + /* Unwind of this frame is not possible. Return outer_frame_id to stop the
>>> + unwinding. */
>>> + if (cache == NULL)
>>> + {
>>> + *this_id = outer_frame_id;
>>> + return;
>>> + }
>>
>> Please let's not add more uses of outer_frame_id if we can avoid it. We're getting
>> close to eliminating it. Can a cache object still be returned, and then a frame id
>> be successfully computed?
>
> Sorry, is that deprecation of outer_frame_id documented somewhere? I haven't seen any warnings or
> comments stating it is not supposed to be used.
It's not strictly deprecated, but it's better to avoid abusing it for cases it isn't meant for,
and fill in the frame id with the best info possible.
The frame in question is not an outer frame, it has a frame address. We just happened
to fail to unwind from it.
>
> It was even made more explicit with this commit:
>
> commit 84154d166a1a4592c70e2a8296d5df0ad7f89be9
> Author: Simon Marchi <simon.marchi@efficios.com>
> Date: Mon Aug 31 13:23:12 2020 -0400
>
> gdb: introduce explicit outer frame id kind
>
That actually removed explicit uses of outer_frame_id. The explicit FID_STACK_OUTER
id kind is only used for the debug prints, as mentioned in the commit log.
The following patch removed even more explicit checks for outer_frame_id:
commit 22b9b4b05bfad806eb3d16535dcd4dbedb028c40
Author: Scott Linder <scott@scottlinder.com>
AuthorDate: Mon Aug 31 13:24:20 2020 -0400
Commit: Simon Marchi <simon.marchi@efficios.com>
CommitDate: Mon Aug 31 13:25:05 2020 -0400
gdb: support frames inlined into the outer frame
>
> So this is a bit confusing.
>
prev parent reply other threads:[~2022-10-13 13:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 9:17 Torbjörn SVENSSON via Gdb-patches
2022-10-13 9:46 ` Luis Machado via Gdb-patches
2022-10-13 11:21 ` Pedro Alves
2022-10-13 12:24 ` Torbjorn SVENSSON via Gdb-patches
2022-10-13 13:25 ` Pedro Alves
2022-10-13 13:11 ` Luis Machado via Gdb-patches
2022-10-13 13:41 ` Pedro Alves [this message]
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=c449141a-4369-a59d-ccda-0ce837a9e78c@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--cc=torbjorn.svensson@foss.st.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