The 11/26/2023 14:37, Richard Sandiford wrote:
> Szabolcs Nagy <szabolcs.n...@arm.com> writes:
> > +++ b/gcc/testsuite/gcc.target/aarch64/eh_return-3.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -mbranch-protection=pac-ret+leaf" } */
>
> Probably best to add -fno-schedule-insns -fno-schedule-insns2, so that the
> instructions in the check-function-bodies are in a more predictable order.
>
> > +/* { dg-final { check-function-bodies "**" "" "" } } */
> > +
> > +/*
> > +**foo:
> > +** hint 25 // paciasp
> > +** stp x0, x1, .*
> > +** stp x2, x3, .*
> > +** cbz w2, .*
> > +** mov x4, 0
> > +** ldp x2, x3, .*
> > +** ldp x0, x1, .*
> > +** cbz x4, .*
> > +** add sp, sp, x5
> > +** br x6
> > +** hint 29 // autiasp
> > +** ret
> > +** mov x5, x0
> > +** mov x6, x1
> > +** mov x4, 1
> > +** b .*
> > +*/
>
> What's the significance of x3 here? It looks from the function definition
> like it should be undefined. And what are the stps and ldps doing?
x0,..,x3 are preserved registers for eh (EH_RETURN_DATA_REGNO).
they are saved in the prologue and restored in the epilogue so
they can pass arguments to eh, which i think is relevant to an
eh_return test, although if the compiler knows they are not
clobbered then it could eliminate the save/restore.
> If those aren't an important part of the test, it might be better
> to stub them out with "...", e.g.:
i can do that.
> /*
> **foo:
> ** hint 25 // paciasp
> ** ...
> ** cbz w2, .*
> ** mov x4, 0
> ** ...
> ** cbz x4, .*
> ** add sp, sp, x5
> ** br x6
> ** hint 29 // autiasp
> ** ret
> ** mov x5, x0
> ** mov x6, x1
> ** mov x4, 1
> ** b .*
> */
>
> LGTM otherwise.
thanks.
