Re: [musl] [PATCH] ppc64: check for AltiVec in setjmp/longjmp

[Markus Wichmann <nullplan@gmx.net>]

On Tue, Dec 07, 2021 at 01:27:08PM -0500, James Y Knight wrote:
> The important question at hand is whether the hardware treats "next
> instruction" as a critical part of the special case. The recommended
> sequence is:
>   bcl 20,31,$+4
>   next-instructions...
>
> But, does the hardware _also_ trigger the expected special-cased effect on
> the return stack when jumping to locations other than the next instruction?
> E.g. is this OK w.r.t. return-stack?
>   bcl 20,31,$+8
>   .long __hwcap-.
>   next-instructions...
>
> On X86, calling *exactly* the next instruction is how you trigger the
> special-case in the return-stack-predictor. But, it sounds like
> potentially on PPC, the address is not part of what triggers the
> special-case. Is that correct?
>

In all the code I've read, people seem to gravitate towards the +4 form
if they can possibly help it. So I guess it really is the entire
instruction that is special. That said, architecturally the right thing
will happen either way, and if any kind of shadow stack is even involved
or successfully circumvented is in the hands of the implementation, and
all implementers whose documentation I have read so far have been very
stingy on implementation details like this.

The difference with X86 is that in case of PPC we are using a different
instruction entirely to get the instruction pointer. X86 only has the
one call instruction. Also, I'd thought the return stack was the reason
for GNU to add linkonce capability to the linker. Because at some point
I started seeing linkonce functions that read the return address into a
register and return crop up in assembler listings generated by GCC. I
didn't know there was a way to circumvent that stack.

Ciao,
Markus