On Wed, Oct 12, 2016 at 11:04:18PM +0100, Maciej W. Rozycki wrote: > On Wed, 12 Oct 2016, James Hogan wrote: > > > > Then I think it makes sense even more not to create this artificial API > > > and use the CP1C.FRE/CP1C.NFRE registers instead which do correspond to > > > what hardware presents to user software. > > > > well, barely. Linux at least doesn't enable Config5.UFE or Config5.UFR, > > since FP mode changes must be done for all threads in the process, so > > userland can't actually directly access those FCRs either. > > Hmm, I didn't know that -- what was the reason for this design decision? > Offhand the limitation does not appear necessary to me, each thread has > its own distinct register set, so it does not appear to me that its mode > of operation has to be the same across them all. The current setting > would still of course be inherited from the parent by any new threads > created with clone(2). Paul Burton & Matt Fortune know the details and can correct me if I'm wrong, but I believe the idea is that the mode change will usually be initiated by the dynamic loader in repsonse to loading a new shared library with a more specific FPU ABI (but must of course be compatible with the current mode). As such you must be careful that all threads in the process change mode so that they can immediately start using the new dynamically loaded code using the more specific ABI. https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#10.5.2._Setting_the_FPU_mode > > (disclaimer: I haven't looked at this gdb patchset in detail as to > > whether any of below has changed since I worked on it). > > > > (1) Even singles and doubles always overlap one another, as do odd > > singles and doubles when FR=1 (and FRE=0): > > /* (little endian) */ > > union __gdb_builtin_mips_fp64 { > > float f32; > > double f64; > > int32 i32; > > int64 i64; > > }; > > > > (2) Odd singles when FR=0 (there are no odd doubles): > > union __gdb_builtin_mips_fp32 { > > float f32; > > int32_t i32; > > }; > > > > (3) Odd singles and doubles when FR=1, FRE=1 don't overlap at all: > > struct __gdb_builtin_mips_fp96 { > > union { > > double f64; > > int64 i64; > > }; > > union { > > float f32; > > int32 i32; > > }; > > }; > > > > i.e. > > > > FR=0: > > (1) even > > double: FEDCBA9876543210 > > single: 76543210 > > (2) odd > > single: FEDCBA98 > > > > FR=1, FRE=0: > > (1) even > > double: FEDCBA9876543210 > > single: 76543210 > > (1) odd > > double: 0123456789ABCDEF > > single: 89ABCDEF > > > > FR=1, FRE=1: > > (1) even > > double: FEDCBA9876543210 > > single: 76543210 (Hybrid FPR emulation) > > (3) odd > > double: 0123456789ABCDEF > > single: FEDCBA98 (Hybrid FPR emulation) > > ) > > I haven't got to this part so far and either way will have to think about > it yet. For one as I noted we do want to present vector (paired-single) > data with FR=1, FRE=0 in addition to what you quoted above. Right, I hadn't looked into that. > This was all > implemented in an old MIPS UK patch originally written by Nigel Stephens > and included with SDE, which I've never got to upstreaming; have you by > any chance based your work on that? No. > As to FR=1, FRE=1 your quoted representation of singles is a software > convention only, so I'm not sure offhand how we might represent it in GDB > to keep it reasonable; the 96-bit cooked FP register structure does not > appeal to me at all TBH, but maybe it's the best we can do after all. Me neither, but it at least seems to look reasonable from an assembly debugging point of view. It took some effort to bend GDB to my will to be honest, especially around mode changes and the remote protocol (since the remote could change from FR=0 (32-bit FP registers) to FR=1 (64-bit FP registers even on 32-bit) at almost any time, but I'm really no gdb expert. Cheers James
Attachment:
signature.asc
Description: Digital signature