Hi Ian,
thank you very much! I already got an off-list answer from Peter Green
which seems to work well (at least, it passes my tests), and I uploaded
a version that supports all arm platforms now. The code is:
.file "zsvjmp.s"
.arch armv8-a
.text
.global zsvjmp_
.type zsvjmp_, %function
zsvjmp_:
str xzr, [x1] // *status = 0;
str x1, [x0], 8 // ((long **)buf)[0] = status
// also post-increment x0 by 8: 1st arg for sigsetjmp
mov w1, 0 // 0 --> 2nd arg for sigsetjmp
b __sigsetjmp // call sigsetjmp
(Using @ as comment delimiter did not work, so I switched to //)
Best regards
Ole
On 02.01.2018 11:06, Ian Campbell wrote:
> On Mon, 2018-01-01 at 15:20 +0100, Ole Streicher wrote:
>> However, I have no idea how to write the same for the 64-bit platform
>> arm64 (the code in the repo does not work). Maybe someone could help
>> me here? Preferably under the IRAF license [3], so that it can be
>> included upstream later.
>
> My arm ASM is a bit rusty but doesn't this first instruction:
> stp x29, x30, [sp, -32]!
> cause sp to be updated (due to the "!")? That leaves the current stack
> frame unbalanced since nothing undoes the push before the branch to
> __sigsetjmp which cannot itself know to undo that change, so presumably
> when __sigsetjmp (or whatever comes next) tries to return over this
> stack frame explodes.
>
> It looks like the intention is to preserve x29 in order to use it as a
> scratch register, perhaps just use one of the caller saved registers
> instead? (infocentre.arm.com seems to be down so I can't refresh my
> memory which registers that would be).
>
> Compared to the armhf version it seems to be making a lot of use of
> spilling things to the stack slots created by moving sp, and seems to
> do awful lot of pointless looking shuffling (although I've not fully
> traced through to try and figure out what it thinks it is doing). Does
> a more direct translation of the armhf code work, something like
> (uncompiled/untested):
>
> str xzr, [x1] @ *status = 0
> str x1, [x0] @ buf[0] = status
> add x0, x0, #8 @ &buf[1] --> 1st arg for sigsetjmp
> mov x1, xzr @ 0 --> 2nd arg for sigsetjmp
> b __sigsetjmp @ call sigsetjmp
>
> Apart from changing the register names the main difference from armhf
> is the use of xzr instead of loading 0 into r2 and the array step being
> 8 instead of 4. I also dropped the explicit 0 offsets on the stores,
> not sure if that might be possible on the armhf side too -- perhaps the
> eventual instruction encoding is the same either way.
>
> I hardly feel like it deserves my copyright, but for formalities sake
> please feel free to take the above snippet under an IRAF license.
>
> Ian.
>
