On Sun, 14 Jul 2024, Jiaxun Yang wrote: > >> > Yes, sure for reads, but how about *writing* to the bit? > >> > >> Tested flipping nan2008 bits with ieee754=emulated with ptrace, it works on some extent. > >> (flipping the bit to unsupported value immediately triggered emulation). > > > > What about the other way round? > > It works on both side (NaN2008 binary with ptrace flipped back to legacy and legacy flipped > back to NaN2008). So this is clearly wrong for this scenario. > > Anyway I think we need to prevent it from happening, matching runtime > > behaviour, i.e. if the program itself cannot flip FCSR.NAN2008 via CTC1, > > then ptrace(2) must not either. And the same for the emulator in the > > "ieee754=emulated" mode (but not for the emulator modes where the flipping > > is currently permitted), as it would be a one-way switch. > > It is out of the scope of this patch I think. Maybe we need a prctl to > set NaN2008 status. I don't know what prctl(2) has to do with this. If you don't implement this part, then your change will cause Linux to behave inconsistently and therefore I'll have to NAK it. It's not much to do anyway, as I have prepared `ptrace_setfcr31' already to handle masking correctly, so all you have to do is to set the mask as required for the right thing to happen. I shouldn't have needed to point you at it though, as that code is easy to find. > We are unable to prevent user applications write NAN2008 bits for the "switchable > QEMU" as well. So I'd perfer leave it as is, and let this feature go into 6.11 so people > can start to use it. This doesn't matter either, as your change only addresses the case where FCSR.NAN2008 isn't writable anyway, which is the sole reason you want to switch between native hard float support and emulation, doesn't it? In fact where FCSR.NAN2008 is writable your new mode has to be equivalent to "ieee754=strict", because then there is no need to trigger emulation for either NaN mode. Please do verify that this is the case. > This is actually a request from Debian MIPS team so they can get glibc tests run on > mismatched NaN hardware. That doesn't matter for us here (and I have a bad suspicion anyway), but the Debian team is of course free to do what they want here, the GNU GPL applies. And also they can always use the "nofpu" kernel parameter to run their verification. I used it for mine back at ImgTec before 2008 NaN hardware was available, also to verify emulation, which I wrote too. Perhaps that is also the right solution for Debian actually? Maciej
