Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use

Andreas Krebbel <[email protected]>
Newsgroups gmane.linux.debian.devel.bugs.rc,gmane.linux.debian.ports.s390
Message-ID <[email protected]>
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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.