about summary refs log tree commit diff
path: root/src/libstd
diff options
context:
space:
mode:
authorMazdak Farrokhzad <twingoow@gmail.com>2019-02-13 18:12:39 +0100
committerGitHub <noreply@github.com>2019-02-13 18:12:39 +0100
commit05cfcb5eb2ad816712d5b047747f14e92b2575a0 (patch)
tree7c8656ec979db015bf10de0754069c549ecb8840 /src/libstd
parent0178f31869116e53f2cd2647d801fe0541efc691 (diff)
parent15e4bd3bf460a4a943465534132a9d3eda5eb798 (diff)
downloadrust-05cfcb5eb2ad816712d5b047747f14e92b2575a0.tar.gz
rust-05cfcb5eb2ad816712d5b047747f14e92b2575a0.zip
Rollup merge of #58420 - dvdhrm:target-uefi-comments, r=nagisa
target/uefi: clarify documentation

This clarifies why FP-units are disabled on UEFI targets, as well as
why we must opt into the NXCOMPAT feature.

I did find some time to investigate why GRUB and friends disable FP on
UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it
turns out it does not mandate enabling the instruction sets explicitly.
Hence, any use of these instructions will trigger CPU exceptions,
unless an application explicitly enables them (which is not an option,
as these are global flags that better be controlled by the
kernel/firmware).

Furthermore, UEFI systems are allowed to mark any non-code page as
non-executable. Hence, we must make sure to never place code on the
stack or heap. So we better pass /NXCOMPAT to the linker for it to
complain if it ever places code in non-code pages.

Lastly, this fixes some typos in related comments.

r? @alexcrichton
Diffstat (limited to 'src/libstd')
0 files changed, 0 insertions, 0 deletions