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

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

On Wed, 2021-05-05 at 17:32 +0000, Thorsten Glaser wrote:
[...]
> > > > @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?
Please send patches.  If you have a test base that could catch bugs
like this (without writing lists of registers in the test itself), that
would be really useful.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20210505/ca619b4b/attachment.sig>

On 5/5/21 7:32 PM, Thorsten Glaser wrote:
> 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.)
f4 and f6 is correct for 32 bit. Sorry for the confusion. Here a link to the 32
bit ABI:
https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_s390.html

Andreas
> 
>>>> ? 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
>