On 12/08/2015 03:10 PM, Kevin Wolf wrote: [...] >>>> Not a compiler bug. gcc uses a floating point register 8 to spill >>>> the pointer of blk (which is call saved) submit_request will later >>>> on call qemu_coroutine_enter and after returning from >>>> qemu_coroutine_enter, the fpr8 contains junk. Not sure yet, what happened. >>> >>> Coroutines don't save the FPU state, so you're not supposed to use >>> floating point operations inside coroutines. That the compiler spills >>> some integer value into a floating point register is a bit nasty... >> >> Just checked. bdrv_aligned_preadv does also use fprs (also for filling >> and spilling). Some versions of gcc seem to like that as the LDGR and LGDR >> instructions are pretty cheap and move the content from/to fprs in a bitwise >> fashion. So this coroutine DOES trash floating point registers. >> >> Without the patch gcc seems to be fine with the 16 gprs and does not >> spilling/filling from/to fprs in bdrv_aligned_preadv. > > Actually, on closer look it seems that the reason why there is no code > for saving the floating point registers in setjmp() on x86 is that they > are caller-save registers anyway, so it doesn't have to. Otherwise the > internet seems to be of the opinion that longjmp() must indeed restore > floating point registers. > > So this might be a libc bug on s390 then.
Fixed with https://sourceware.org/ml/libc-alpha/2013-01/msg00853.html Christian
