Hello Eugene, Looks like we're done with this. Thanks for all the help! Cheers, Michael On 11/20/2016 06:34 PM, Eugene Syromyatnikov wrote: > On Sun, Nov 20, 2016 at 06:26:37PM +0100, Michael Kerrisk (man-pages) wrote: >> Hello Eugene, >> >> On 11/20/2016 03:59 PM, Eugene Syromyatnikov wrote: >>> On Sun, Nov 20, 2016 at 12:27:28PM +0100, Michael Kerrisk (man-pages) wrote: >>>> Hi Eugene, >>>> >>>> I have applied this patch and tweaked some pieces (and pushed to Git), >>>> but some parts need work still, I think. See my comments below. >>>> >>>> Rather than sending a patch, I think it would be easier if you just >>>> respond to my comments in line below. >>>> >>>> >>>> On 11/20/2016 01:55 AM, Eugene Syromyatnikov wrote: >>>>> Based on description provided in commit 9791554b and information in >>>>> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking >>>>> --- >>>>> man2/prctl.2 | 100 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 100 insertions(+) >>>>> >>>>> diff --git a/man2/prctl.2 b/man2/prctl.2 >>>>> index ae1fbc5..954641c 100644 >>>>> --- a/man2/prctl.2 >>>>> +++ b/man2/prctl.2 >>>>> @@ -263,6 +263,98 @@ or >>>>> Return the endian-ness of the calling process, >>>>> in the location pointed to by >>>>> .IR "(int\ *) arg2" . >>>>> +.\" 9791554b45a2acc28247f66a5fd5bbc212a6b8c8 >>>>> +.TP >>>>> +.BR PR_SET_FP_MODE " (since Linux 4.0, only on MIPS)" >>>>> +On MIPS, user land code can be built using ABI which permits linking with a code >>>>> +with a more restrictive floating point requirements. For example, user land >>>>> +code may be built to target the O32 FPXX ABI and linked with code built for >>>>> +either one of the more restrictive FP32 or FP64. When more restrictive code is >>>>> +linked in, the overall requirement for the process is to use this more >>>>> +restrictive floating point mode. Since kernel has no means of knowing in advance >>>>> +which mode process should be executed in, and having possibility that these >>>>> +restrictions can be changed during the process' lifetime, >>>> >>>> I have trouble to understand "and having possibility that these >>>> restrictions can be changed during the process' lifetime". >>>> >>>> I think the main problem is: who can do the changing? >>>> It's not clear from the sentence. Can you explain a little? >>> >>> Yes, you are correct; probably the note regarding the time of change is >>> rather misleading; the need for change which can be determined only from user >>> space is what has lead to such interface. >> >> So, how would the wording be: >> >> [[ >> Because the kernel has no means of knowing in advance >> which mode the process should be executed in, >> and because the ABI restrictions can >> change over the lifetime of the process, the >> .B PR_SET_FP_MODE >> operation is provided to allow control of the floating-point mode >> from user space. >> ]] > > Loooks fine. > >>>>> the ability to control >>>>> +it from the user space via this option is provided. >>>> >>>> Does "it" in the previous line mean "the floating-point mode"? >>> Yes. >> >> Thanks. >> >>>>> + >>>>> +.\" https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking >>>>> +The >>>>> +.I (unsigned int) arg2 >>>>> +argument is a bit mask describing floating point mode used: >>>>> +.RS >>>>> +.TP >>>>> +.BR PR_FP_MODE_FR " = " "(1 << 0)" >>>> >>>> I removed the piece [" = " "(1 << 0)"] (and similar below), since >>>> presumably user-space doesn't need to know the precise numeric >>>> values. >>> Yes, sure. >> >> Okay. >> >>>>> +When this bit is >>>>> +.I unset >>>>> +(so called >>>>> +.BR FR=0 " or " FR0 >>>>> +mode), 32 FP registers are 32-bit wide, and 64-bit registers are represented as >>>> >>>> What are "32 FP registers"? (And again below.) >>>> >>>> Perhaps this is just a language issue. Should it be "the 32 FP registers"? >>>> (The lack of an article--"the" or "a"--can sometimes be fatal to >>>> comprehension in English.) >>> Yes, you are correct, I meant the amount of floating point registers available. >> >> Okay. Fixed. >> >>>>> +pair of registers (even- and odd- numbered, with even-numbered register >>>>> +containing lower 32 bits, and odd-numbered register containing higher 32 bits). >>>>> +When this bit is >>>>> +.I set >>>>> +(on supported hardware), 32 FP registers are 64-bit wide (so called >>>> >>>> "the 32 FP registers"? >>> Right. >> >> Fixed. >> >>>>> +.BR FR=1 " or " FR1 >>>>> +mode). Note that modern MIPS implementations (MIPS R6 and newer) support >>>>> +.B FR=1 >>>>> +mode only. >>>>> + >>>>> +Applications that use O32 FP32 ABI can operate only when this bit is >>>>> +.I unset >>>>> +.RB ( FR=0 ; >>>>> +or they can be used with FRE enabled, see below). >>>>> +Applications that use O32 FP64 ABI (and O32 FP64A ABI, which exists for >>>>> +providing ability to operate with existing FP32 code; see below) can operate >>>>> +only when this bit is >>>>> +.I set >>>>> +.RB ( FR=1 ). >>>>> +Applications that use O32 FPXX ABI can operate in both cases. >>>> >>>> What does "both cases" mean in the above line? >>> Both in case of FR=0 and FR=1. >> >> So, I made this: >> [[ >> Applications that use the O32 FPXX ABI can operate in with either >> .BR FR=0 >> or >> .BR FR=1 . >> ]] >> >> Okay? > > Yes, sure. > >>>>> +.TP >>>>> +.BR PR_FP_MODE_FRE " = " "(1 << 1)" >>>>> +Compatibility with 32-bit FP mode. When this mode is enabled, it emulates 32-bit >>>> >>>> I think the first sentence needs at least one or two more words. Is >>>> >>>> Provide compatibility with 32-bit FP mode. >>>> >>>> correct? >>> Yes. Another possibility is "Enable emulation of 32-bit FP mode". >> >> Ah that's better. Changed. >> >>>>> +FP operations by raising reserved instruction exception on every instruction >>>>> +that uses 32-bit formats and kernel then handles the instruction in software >>>>> +(the problem lies in discrepancy of handling odd-numbered registers which are >>>>> +high 32 bits of 64-bit registers with even numbers in >>>>> +.B FR=0 >>>>> +mode and lower 32-bit parts of odd-numbered 64-bit registers in >>>>> +.B FR=1 >>>>> +mode). Enabling of this bit is needed when code with O32 FP32 ABI should operate >>>>> +with code with compatible O32 FPXX or O32 FP64A ABIs (which require >>>>> +.B FR=1 >>>>> +FPU mode) or when it is executed on newer hardware (MIPS R6 onwards) which lacks >>>>> +.B FR=0 >>>>> +mode support when binary with FP32 ABI is used. >>>>> +.IP >>>>> +Note that this mode only makes sense when FPU is in 64-bit mode >>>>> +.RB ( FR=1 .) >>>>> +.IP >>>>> +Note that usage of emulation inherently has a significant performance hit and >>>>> +should be avoided if possible. >>>>> +.RE >>>>> +.IP >>>>> +Note that for N32/N64 ABI is a different story and does not need FPU emulation >>>>> +and always operates in >>>>> +.B FR=1 >>>>> +mode. >>>> >>>> That last sentence is a bit hard to parse. Would the following be okay: >>>> >>>> [[ >>>> For the N32/N64 ABI, the story is different story: FPU emulation >>>> is not required and the FPU always operates in >>>> .B FR=1 >>>> mode. >>>> ]] >>>> >>>> ? >>> Maybe >>> >>> [[ >>> In N32/N64 ABI, 64-bit FP mode is always used, so FPU emulation >>> is not required and the FPU always operates in >>> .B FR=1 >>> mode. >>> ]] >>> >>> ? >> >> Good. Taken as you gave it. Thanks. >> >>>>> +.IP >>>>> +This option is mainly intended for use by dynamic loader, but may be of use by >>>>> +applications in case library loading during runtime (via >>>>> +.BR dlopen (3), >>>>> +for example) is used. >>> Please discard the note regarding dlopen, I've incorrectly interpreted >>> the glibc code found in sysdeps/mips/tst-abi-interlink.c; looks like >>> glibc also accounts for libraries loaded via dlopen too (as noted in >>> sysdeps/mips/dl-machine-reject-phdr.h); as a result, >>> looks like this command is of little use for user applications and intended >>> mainly for libc implementations (or some very specific applications which >>> have to deal with pre-generated FP code, maybe). >> >> So, then just replace those lines with: >> >> This option is mainly intended for use by dynamic loader. >> >> ? > > Yes, thanks. > >> (Current version pushed to Git.) >> >> Thanks, >> >> Michael >> >> -- >> Michael Kerrisk >> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ >> Linux/UNIX System Programming Training: http://man7.org/training/ > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
