PR_SET_FP_MODE(2const)
π PR_SET_FP_MODE (2const) π
okay bestie, welcome to the group chat. this is PR_SET_FP_MODE, a <linux/prctl.h> / <sys/prctl.h> situation, and we're gonna talk about it in the same tone you'd use to explain to your friend why their ld.so is acting up at 2am. grab a snack. π
πΈ NAME πΈ
PR_SET_FP_MODE β set the floating point mode of the calling process β¨
π LIBRARY π
Standard C library (libc, -lc) β the classic, the icon, the one everybody links against π
π SYNOPSIS π
#include <linux/prctl.h> /* Definition of PR_* constants */
#include <sys/prctl.h>
int prctl(PR_SET_FP_MODE, unsigned long mode);
that's the whole vibe right there. one call, one mode bit mask, one process whose floating-point life is about to change. π¦
β¨ DESCRIPTION β¨
okay so picture this: you're on MIPS. and on MIPS, user-space code can be built using an ABI that lets it link with code that has more restrictive floating-point (FP) requirements. it's giving "we can be friends even though your standards are stricter than mine." π
for example?? user-space code could be built to target the O32 FPXX ABI and then linked with code built for either one of the more restrictive FP32 or FP64 ABIs. and here's the thing: once that more restrictive code gets linked in, the overall requirement for the process is that it has to use the more restrictive floating-point mode. no negotiation. that's the new law of the land. π
and like, the kernel genuinely has no means of knowing in advance which mode the process should be executed in. also these restrictions can literally change over the lifetime of the process. so PR_SET_FP_MODE exists β it's the operation that lets user space be the main character and control the floating-point mode itself. periodt. π
the mode argument is a bit mask describing the floating-point mode used, and here's the tea on the bits:
PR_FP_MODE_FRβ the big one, buckle up π
when this bit is unset (so-called FR=0 or FR0 mode), the 32 floating-point registers are 32 bits wide, and 64-bit registers are represented as a pair of registers β even- and odd-numbered, with the even-numbered register containing the lower 32 bits, and the odd-numbered register containing the higher 32 bits. two halves of one whole. iconic honestly.
when this bit is set (on supported hardware), those 32 floating-point registers are 64 bits wide (so-called FR=1 or FR1 mode). note that modern MIPS implementations β MIPS R6 and newer β support FR=1 mode only. they said no to the old ways. π
and the compatibility lore:
- applications that use the O32 FP32 ABI can operate only when this bit is unset (FR=0; or they can be used with FRE enabled, see below π)
- applications that use the O32 FP64 ABI (and the O32 FP64A ABI, which exists to provide the ability to operate with existing FP32 code; see below) can operate only when this bit is set (FR=1)
- applications that use the O32 FPXX ABI can operate with either FR=0 or FR=1. flexible queen. π
PR_FP_MODE_FREβ enable emulation of 32-bit floating-point mode π§
when this mode is enabled, it emulates 32-bit floating-point operations by raising a reserved-instruction exception on every instruction that uses 32-bit formats, and then the kernel handles that instruction in software. (and the problem?? it lies in the discrepancy of handling odd-numbered registers β which are the high 32 bits of 64-bit registers with even numbers in FR=0 mode, versus the lower 32-bit parts of odd-numbered 64-bit registers in FR=1 mode. the drama of register numbering, truly.)
enabling this bit is necessary when:
- code with the O32 FP32 ABI should operate with code with compatible the O32 FPXX or O32 FP64A ABIs (which require FR=1 FPU mode), or
- it is executed on newer hardware (MIPS R6 onwards) which lacks FR=0 mode support, when a binary with the FP32 ABI is used
π«Ά note: this mode makes sense only when the FPU is in 64-bit mode (FR=1).
π note: the use of emulation inherently has a significant performance hit and should be avoided if possible. software emulation is not it, bestie. it is lowkey a slow-motion tragedy.
okay and for the N32/N64 ABI: 64-bit floating-point mode is always used, so FPU emulation is not required and the FPU always operates in FR=1 mode. no choices to make, no bits to sweat. slay. β¨
this operation is mainly intended for use by the dynamic linker (ld.so(8)). yeah. the linker is the one calling the shots here. iykyk. π
π₯ RETURN VALUE π₯
- on success,
0is returned π - on error,
-1is returned, anderrnois set to indicate the error π
π€ ERRORS π€
EOPNOTSUPPβmodehas an invalid or unsupported value. the bit mask said something the kernel simply cannot with. π
π STANDARDS π
Linux. MIPS only. ngl that's a pretty exclusive guest list. π
π°οΈ HISTORY π°οΈ
Linux 4.0 (MIPS). vintage-ish but make it MIPS. π¦
π SEE ALSO π
prctl(2)PR_GET_FP_MODE(2const)β the getter to this setter, the reading to this writing, the bestie to this bestie π
and that's the page!! shoutout to the Linux man-pages 6.20 girlies, this one was dated 2026-02-08, and it lives under the PR_SET_FP_MODE(2const) banner. go forth, set your floating-point mode, and remember: FR=0 and FR=1 are both valid, but only one of them is ever going to be the vibe your linked code actually needs. πβ¨π
π¦ where this page comes from
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- π the page's license: Linux-man-pages-copyleft
- Copyright 2016, Eugene Syromyatnikov <evgsyr@gmail.com>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms