From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Srinath Parvathaneni <srinath.parvathaneni@arm.com>,
gcc-patches@gcc.gnu.org
Cc: richard.earnshaw@arm.com, kyrylo.tkachov@arm.com
Subject: Re: [PATCH][GCC] arm: Add support for new frame unwinding instruction "0xb5".
Date: Fri, 20 Jan 2023 16:59:50 +0000 [thread overview]
Message-ID: <2adfc900-284d-7345-5e46-c64d76e9a221@foss.arm.com> (raw)
In-Reply-To: <c24cd3a3-6f3f-437d-b7ec-a9fea09378df@AZ-NEU-EX04.Arm.com>
On 10/11/2022 10:37, Srinath Parvathaneni via Gcc-patches wrote:
> Hi,
>
> This patch adds support for Arm frame unwinding instruction "0xb5" [1]. When
> an exception is taken and "0xb5" instruction is encounter during runtime
> stack-unwinding, we use effective vsp as modifier in pointer authentication.
> On completion of stack unwinding if "0xb5" instruction is not encountered
> then CFA will be used as modifier in pointer authentication.
>
> [1] https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf
>
> Regression tested on arm-none-eabi target and found no regressions.
>
> Ok for master?
>
> Regards,
> Srinath.
>
> gcc/ChangeLog:
>
> 2022-11-09 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
>
> * libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode opcode
> "0xb5".
>
>
> ############### Attachment also inlined for ease of reply ###############
>
>
> diff --git a/libgcc/config/arm/pr-support.c b/libgcc/config/arm/pr-support.c
> index e48854587c667a959aa66ccc4982231f63333ecc..73e4942a39b34a83c2da85def6b13e82ec501552 100644
> --- a/libgcc/config/arm/pr-support.c
> +++ b/libgcc/config/arm/pr-support.c
> @@ -107,7 +107,9 @@ __gnu_unwind_execute (_Unwind_Context * context, __gnu_unwind_state * uws)
> _uw op;
> int set_pc;
> int set_pac = 0;
> + int set_pac_sp = 0;
> _uw reg;
> + _uw sp;
>
> set_pc = 0;
> for (;;)
> @@ -124,10 +126,11 @@ __gnu_unwind_execute (_Unwind_Context * context, __gnu_unwind_state * uws)
> #if defined(TARGET_HAVE_PACBTI)
> if (set_pac)
> {
> - _uw sp;
> _uw lr;
> _uw pac;
> - _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
> + if (!set_pac_sp)
> + _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32,
> + &sp);
> _Unwind_VRS_Get (context, _UVRSC_CORE, R_LR, _UVRSD_UINT32, &lr);
> _Unwind_VRS_Get (context, _UVRSC_PAC, R_IP,
> _UVRSD_UINT32, &pac);
> @@ -259,7 +262,19 @@ __gnu_unwind_execute (_Unwind_Context * context, __gnu_unwind_state * uws)
> continue;
> }
>
> - if ((op & 0xfc) == 0xb4) /* Obsolete FPA. */
> + /* Use current VSP as modifier in PAC validation. */
> + if (op == 0xb5)
> + {
> + if (set_pac)
> + _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32,
> + &sp);
> + else
> + return _URC_FAILURE;
I don't think you need to worry about the case when set_pac is false; in
fact, I don't think you need to even test set_pac here. It's harmless
if this opcode appears and then we never do the authentication, so just
record the SP value at this point.
> + set_pac_sp = 1;
> + continue;
> + }
> +
> + if ((op & 0xfd) == 0xb6) /* Obsolete FPA. */
No, this is logically impossible (0xfd is binary 1111_1101, while 0xb6
is binary 1011_110 and thus bit 2 will never be set after the mask).
But you don't need to change the condition here at all, because we've
already taken out the case you're worried about immediately above (and
ended that block with a 'continue').
> return _URC_FAILURE;
> > /* op & 0xf8 == 0xb8. */
>
>
>
R.
prev parent reply other threads:[~2023-01-20 16:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 10:37 Srinath Parvathaneni
2022-11-17 20:27 ` Ramana Radhakrishnan
2022-11-18 9:33 ` Srinath Parvathaneni
2022-11-20 22:48 ` Ramana Radhakrishnan
2023-01-18 17:56 ` Srinath Parvathaneni
2023-01-20 16:59 ` Richard Earnshaw [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=2adfc900-284d-7345-5e46-c64d76e9a221@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kyrylo.tkachov@arm.com \
--cc=richard.earnshaw@arm.com \
--cc=srinath.parvathaneni@arm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).