klibc - May 2021 - Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

On 5/5/21 4:45 AM, Thorsten Glaser wrote:
> Dixi quod?
> 
>> Jessica Clarke brought out docs saying f8?f15 must be saved, the
>> other FPU registers not:
I can confirm this. It is f8-f15 for the z/Architecture (64 bit). It is f1, f3,
f5, f7 for the ESA
architecture (32 bit) which is still supported by Glibc and GCC.
> 
> This needs to be fixed in klibc.
> 
>>> ? klibc does not really support the FPU anyway
>>
>> ? GCC chooses to allocate an FPU register for a pointer value.
GCC will put integer values into vector registers for auto-vectorization or for
spilling. We also
use call-clobbered FPRs as save slots for GPRs in leaf-functions if can get rid
of allocating a
stack frame that way.
> 
> This is a curiosity.
> 
>>> ? the half of v10 that equals f10 just HAPPENS to be saved by
>>>  glibc, but what if the upper half, that is outside of the FPU,
>>>  is used?
>>
>> The question here is, does GCC only use the halves of the half
>> of the vector registers that match the FPU registers?
> 
> 04:41??jrtc27:#debian-x32? hephaistor: re s390x vector registers, reading
the gcc and llvm sources they're
>      ?    all call-clobbered by default, only the float parts are
call-saved
> 04:41??jrtc27:#debian-x32? so that's why setjmp/longjmp don't need
to save/restore them
> 04:42??jrtc27:#debian-x32? there *is* a vector calling convention, but
it's not the default for the ABI,
>      ?    it's opt-in, and setjmp/longjmp won't be annotated as
such
> 
> So we indeed need to only save the registers glibc does.
The vector registers are call-clobbered - exactly for the reason of setjmp /
longjmp. Only f8-f15
need to be saved.

You can find the latest version of our ABI here:
https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf

However, it is still lacking the vector ABI extension. I wrote a document for
that which we use
internally and we are working on integrating it into the publicly available
version.

Andreas
> 
>> @klibc list: as indicated earlier, I can provide a patch if needed
>> (though it should be obvious).
> 
> bye,
> //mirabilos
>

Hi Andreas,
>>> Jessica Clarke brought out docs saying f8?f15 must be saved, the
>>> other FPU registers not:
>
>I can confirm this. It is f8-f15 for the z/Architecture (64 bit).
thanks!
>It is f1, f3, f5, f7 for the ESA
>architecture (32 bit) which is still supported by Glibc and GCC.
Is this what we know as s390 in Debian? (klibc saves f4 and f6 there
currently. If so, this also needs to change.)
>>> ? GCC chooses to allocate an FPU register for a pointer value.
>
>GCC will put integer values into vector registers for
>auto-vectorization or for spilling. We also use call-clobbered FPRs as
>save slots for GPRs in leaf-functions if can get rid of allocating a
>stack frame that way.
Ah, interesting. Thanks!
>The vector registers are call-clobbered - exactly for the reason of
>setjmp / longjmp. Only f8-f15 need to be saved.
Right.
>You can find the latest version of our ABI here:
>https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf
>
>However, it is still lacking the vector ABI extension. I wrote a
>document for that which we use internally and we are working on
>integrating it into the publicly available version.
OK, thanks for the information!
>>> @klibc list: as indicated earlier, I can provide a patch if needed
>>> (though it should be obvious).
hpa, maks, bwh: any of you taking these two or should I send patches
and possibly NMU klibc in Debian?

Thanks,
//mirabilos
-- 
<ch> you introduced a merge commit        ?<mika> % g rebase -i
HEAD^^
<mika> sorry, no idea and rebasing just fscked ?<mika> Segmentation
<ch> should have cloned into a clean repo      ?  fault (core dumped)
<ch> if I rebase that now, it's really ugh     ?<mika:#grml>
wuahhhhhh