Thorsten Glaser
2021-May-05 17:32 UTC
[klibc] 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
Ben Hutchings
2021-May-05 18:24 UTC
[klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
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>
Andreas Krebbel
2021-May-06 06:05 UTC
[klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
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 >