[PATCH v6 01/13] ARC: ABI Implementation

Florian Weimer fweimer@redhat.com
Thu Jun 4 09:04:28 GMT 2020


* Vineet Gupta via Libc-alpha:

> On 5/27/20 11:26 AM, Adhemerval Zanella via Libc-alpha wrote:
>> +ENTRY (__longjmp)
>> +
>> +	ld_s r13,   [r0]
>> +	ld_s r14,   [r0,4]
>> +	ld   r15,   [r0,8]
>> +	ld   r16,   [r0,12]
>> +	ld   r17,   [r0,16]
>> +	ld   r18,   [r0,20]
>> +	ld   r19,   [r0,24]
>> +	ld   r20,   [r0,28]
>> +	ld   r21,   [r0,32]
>> +	ld   r22,   [r0,36]
>> +	ld   r23,   [r0,40]
>> +	ld   r24,   [r0,44]
>> +	ld   r25,   [r0,48]
>> +
>> +	ld   blink, [r0,60]
>> +	ld   fp,    [r0,52]
>> +	ld   sp,    [r0,56]
>> +
>> +	mov.f  r0, r1	; get the setjmp return value(due to longjmp) in place
>> +
>> +	j.d    [blink]	; to caller of setjmp location, right after the call
>> +	mov.z  r0, 1	; can't let setjmp return 0 when it is due to longjmp
>> +
>> +END (__longjmp)
>
> So wanted to pick your brains on this thing. While longjmp is not necessarily an
> application hotspot, it seems bulk load/store can in general benefit from with
> ARCv2 double load/store instructions LDD/STD which work with register pairs.
>
> So we could have 2 variants which compile differently to one runtime
> implementation or better still have 2 runtime implementations which could be
> switched to using hwcaps (which I can add to kernel). Does that require IFUNC
> which ARC toolchain doesn't support ATM.

Without IFUNCs, you would have to use a conditional branch in the
(single) __longjmp implementation.

With IFUNCs, all internal callers will have to go through a function
pointer—or those internal callers would have to turn into IFUNCs as
well.

So it's doubtful whether this is beneficial in this case.

Also, please double-check the register list.  The ABI manual says this:

| The scratch registers are not preserved across function calls. When
| calling an external function, the compiler assumes that registers %r0
| through %r12 and %r30 are trashed; and that %r13 through %r29 are
| preserved.  The EV6x processor reserves %r25.

r27 and r28 are handled as fp and sp.  That leaves r26 and r29 as
unhandled.

r25 seems to be the thread pointer.  It cannot change its value between
setjmp and longjmp because you cannot longjmp onto another thread, so
saving and restoring it should not be necessary.

Thanks,
Florian



More information about the Libc-alpha mailing list